okkyの銀河制圧奇譚: 2007-03

2007年3月25日

google-code-prettifyの実験

Pマークのお陰で余計な手間を食ってしまったが…ちょいと実験してみよう。

<code class="prettyprint">
#include <stdio.h>
#include <stdlib.h>
int
main( int argc, char **argv )
{
   printf( "hello world.\n" );
}
</code>

#include <stdio.h> #include <stdlib.h> int main( int argc, char **argv ) { printf( "hello world.\n" ); }

ん？？？じゃぁ、 #include 文を取るとどうだ???!

int main( int argc, char **argv ) { printf( "hello world.\n" ); }

うーむ。#include 系に弱いなぁ。 <> で囲ってあると、blogger 側が勝手にタグと勘違いするらしい。で、これを <> と書き直すと、今度は prettyprint が判らなくなるらしい。

2007年3月24日

日本情報処理開発協会馬鹿丸出し

大日本印刷が個人情報を大量に流出したのに、Pマーク取り消しはないのだそうだ。

Nikkei Net の記事だが、どうやら日本情報処理開発協会は自らの存在意義を否定したようだ。
ちなみにその存在意義を否定した集団自体の発表はこれ。

憶測では、大日本印刷が扱っている業務量が多いために、それらに影響が及ばぬよう…と言うことらしいが、

情報が漏洩しないはずの所が漏洩している段階で被害はすでに甚大である
情報漏洩されては困る情報を大量に扱っていると言うことは、ごく短期間に問題が再発しただけで、被害は爆発的に広がるリスクを持っている

これらを考えるならば、「扱っている業務量が多い」ならばますますのこと、Pマークの即時取り消しが必要であろう。

また、大日本印刷に業務委託している企業は即刻、取引を停止し、そのことを公開することで、自らの顧客に対して、自分たちのセキュリティに関する意識の高さを示すべきだろう。でなければ、それらの企業や自治体も、個人情報などの扱いに関して、著しく意識が低い事を露呈しているだけだ。

最後に。「うちは、もはや信頼のならない Pマーク取得に向けての努力はいたしません」というのは、立派な営業トークになると思う。

2007年3月23日

ソースコードを blog で表示 again

google-code-prettifyなるものがあるらしいのですよ。

使い方は Readme に書いてある程度の説明しかないのですが、これはなかなかよさそうで。

今はソースコード用の css 設定なんか使っていますが、もしかするとこいつを読み込むようにするだけの方が賢くないか(反語)?

つーか、blogger デフォルトでサポートしてくれると、おじさんとっても嬉しいなぁ。

2007年3月20日

いやな事は早く済まそうという…

うんちゃらハック、くんちゃらハックと、なんでも「ハック」とつければ売れそうな勢いの今日この頃ですが。
スピードハックという本を読み終わりました。内容、軽っ。

まぁ、ここに乗っていた Web とかで使えるツール類は便利そうなので使うとして。
ここに乗っていた「仕事の仕方」の大半は自分でやっている事なので、参考にならないとして…。
そもそもそんなに急いで仕事を済ませたいものなのか? と言うのはある。仕事は趣味じゃないんだから、速く終了させられればよいが、出来が悪くては意味が無いのも事実だし…。まぁ、いやな事はとっとと終わらせたい、と言う気持ちは判らなくもないが…。

この調子だと:

受験ハック

とか:

結婚ハック

とか:

お葬式ハック

とか、出そうで怖い。
# つーか結婚ハックは誰かかいてくれ。

この手のハック本って、どうやら Wiki 見たいな所に書き綴ったものを、そのまま本に製本しているだけのようだ。であれば、私も自分が持っている受験ハックをblog で書いて置けば、そのうち本にしてもらえるかもしれないな :p

それぐらいハック本の中身は軽いです。

逆に言うと、中身は軽いから読んでもたいした時間はかからない。もし、仕事のやり方で悩んでいるなら、読んでみてもそんなにたいした損ではないぞ、とも言える。最近の子の手の本は、もしかすると「お得感」ではなく「損しなさ感」で売ってるんだろうか…。

2007年3月19日

ドキドキの向こう側…

久々に出た Bruce Schenier の新作!! つーても、原書は2003年に出ているのだが。相変わらずセキュリティについて判りやすく書かせたら、この人の右に出る人はいない。しかし同時に、どんどんコンピュータセキュリティから離れていってしまう気がする。

まぁ、本書自体の感想は上記のリンクにある私の蔵書リストに任せるとして(そういうサボり方をするんだ…)、この本にはちょろっと言及しているのに、結局そこから先、深彫りしていない項目が1つあるので、それについて書こう。これを本の感想の所に書くと、本の感想なのか何なのか判らなくなるから。

テロなどに襲われる理由の一つに憎たらしいからと言うのがある。もちろん、人によって何が憎たらしいのかは変わるものなのだが、少なくともアメリカ人の唯我独尊振りは世界中に知れ渡り、一部のアメリカ人自身、
「おれはあの我侭なアメリカ人が大嫌いだ」
と主張するぐらいには、唯我独尊である事は認めてもらってもいいだろう、とは思う。この我侭振りと、直接会った場合の人に対する接し方の柔らかさは、まさに田舎者のそれ、そのものと言ってもよいだろう。目の前にあるものが重要で、その外にどれほど広い世界があるのか知らない、という意味で。

個人的にはその田舎者っプリは大好きだったりするのだが、まぁそうは言っても、その田舎者っぷりを全力で出したキリスト教徒が、ユダヤ教とイスラム教どちらを大切にするかと言われれば、そりゃ旧約聖書のお膝元、ユダヤ教なのであって。オリジンを翻訳しちゃいけないなどと言う制約までついているコーランに載っている話を「コーランに載っている話」として聞いたことのあるアメリカ人なんぞ十人に一人いれば多いほうなわけで…。

そんなアメリカ人とイギリス人が勝手にイスラエルなんて国を作ったらそりゃ頭にくるでしょう。しかもそこにいる連中が「ここは昔っからおらの土地だ」なんぞと寝言を吐いたら、どつきたくもなると言うもので。それに対して「大概にしとけよ」と言うのならばともかく「その通りだ」なんぞと言うアメリカ人は…そりゃテロの標的になろうっていうもの。

Beyond Fear の p.320 にはこうある。

反米感情が強い国が多いことから、海外では、カナダ人を装うアメリカ人が多い。

p.332 だと

攻撃者に目をつけられる者にならないのも、防御の一策だ。…企業なら、広報活動に力を入れることと、基本的によき企業市民である事だろうか。国家なら、責任ある行動を世界に示すことかもしれない。評判の悪い方針をとらないというのもひとつの方法だ。

とある。

防御と言う点から考えるならば、投資対効果という点からすれば、これ以上の「テロ防止策」はないだろう。ブッシュの行動や、アメリカの無責任な行動を見るにつけ、まさにこの評判の悪い方針ばかり取る事が、アメリカ最大の防御能力の低さの表れ、と言わざるをえまい。

昔、初めてアメリカに住んだ頃。親に言われたのが、
「日本人の代表だと思って行動しなさい」
と言うことだった。私が無様なことをすれば、日本人全部が無様だと思われる。失礼なことをすれば、日本人全体が失礼だと思われる。だからそのようなことの無いようにしなさい、と。

まぁ、実際問題としては、自分が正しいと思えばなんと言われようと闘うというスタンスになんら変わることはなかったのだが。運よくこのスタンスは「American Justiceのために闘う」というアメリカ人の感性に訴えるものがあったらしく、ものすごく受けがよかった。果たして彼らにとっての日本人像がよくなったのか悪くなったのかは、自信が無いが、少なくとも私という人間の「防御」という観点からは、圧倒的な効果があったことは間違いない。

アメリカのように強大なパワーを持っている国の国民は、国外にいようが国内にいようが、自分の行動が国家の評判を上下するのだ、というスタンスを持って行動しなければ、発生する反感も強大になる。自分たちがいかに親切であるか、説明できるようではダメなのだ。説明できると言うことは、所詮 Countable な頻度でしか親切ではない、と言うことだ。そういう人に限って傲岸不遜振りは説明できないが、それは Uncountable なぐらい傲岸不遜なのだ、と思わなくてはいけない。マザーテレサの偉業を説明しきることなど出来るだろうか?

このような観点がものすごく過小評価されているのが、残念でならない。

2007年3月15日

父ちゃんと息子とその仲間たち

父ちゃんの本を前に紹介したが、当然次は息子の方。

父ちゃんの方は伝記だが、息子の方は自伝である。

英語版は確か1990年に発行され、日本語訳されたのが「IBMの息子」。で、先ごろ、装丁を変え、1冊にまとめられたのが「先駆の才」。内容的にはほとんど変わらないといいますが、古いほうは表紙と厚みぐらいしか知らないので、何ともいえない。もし、父ちゃんの方とセットで集めるなら、新しい装丁の方が良いと思う。

TJW-II は何をやった事で有名かと言うと:

IBMを電子計算機の会社にした。父親は、あくまでもパンチカードと言う「機械式」の計算にこだわったのだ。
TJW-Iが作り上げた社風を、簡潔に、判り易くまとめた。これによって「TJWのdirection」をフランチャイズしやすくした。これが最終的に『安心して判断を任せられるマネージャ』の増産につながり、結果として権限委譲をやりやすくし、これによってIBMの拡大速度を飛躍的に高めた。
特に、IBMの3つの指針はわかりやすさと、実行の難しさで有名。

この二人、やはり似たところがある。

TJW-II も激情型。TJW-I 以上に雷は激しかったと言う。
TJW-I が New York州 Endicott という村を技術拠点として使ったのに対し、TJW-II は New York 州 Poughkeepsie という町を技術拠点とした。

あぁ、なるほど。私が中学1年-2年の夏までいた所か。どうりで Endicott だけでは何か薫陶成分が足りないと思ったら。

この親子の伝記、読んでいて思ったのは…一世の奥さんであるジャネットさんは大変だったろうなぁという事。息子の自伝の方が先に出ているのに対し、父親の方の伝記はIBMの資料庫からの資料も参照しているので、「息子がこう感じていた頃、父親はこう感じていた」的な見方ができて面白いのだが、大半が『感情的にぶつかり合っている』のを家族が周りでおろおろ見ている、という図に落ち着くのが…。

面白いので、是非両方読んでみるとよいでしょう。

2007年3月14日

円/ドル　レート

株が下がると、円が上がる…

ちょっとその、非常識な動き方止めて欲しいなぁ。

夏は OLS とか、アメリカ大陸への出張がありそうなので、ドルが安いときに少し多い目に交換しておこうとにらんでいるんですが、これではいつ交換するといいんだか判らない…。

City Bank の口座は、アメリカ合衆国内でないと使えないので、カナダ直行だと結局意味無いんですけどね。

2007年3月13日

clear_fpu バグ

これは、Linux Kernel の 2.6.7 と 2.4.26で直ったバグについての説明。つまり大昔のバグの話だ。

なぜ、そんなものを、今頃になって、こんな所に、書くのか。

「なぜ」は簡単だ。このバグに関する記述が綺麗にそろっている環境がなかなかないからだ。
じゃぁ、なぜ綺麗にそろっていないかと言うと、それはこの修正の発生時期が

      2004/06/14 16:05:28-03:00

だから。丁度この直後に Linux の revision control システムは bitkeeper から git に入れ替わった。そう、例の Andrew Tridgell 君による「bitkeeper プロトコル解析&クローン作成問題」がこの直後に控えているのだ。

この頃は、Linux の開発は bitkeeperで続けられると、みんな思っていた。このため、『bitkeeperで』このパッチを見つけるにはどうすればいいかを書いたページはたくさんあっても、パッチそのものを掲載しているページは皆無。もちろん例外はあるけれど、この例外が無ければ本当に見つけられなくなるところだった。

せっかく見つけたのだから、自分が探索しやすいところに、探索しやすいように置いておこう、というのが「今頃」「こんな所」に書く理由。

では、なぜこのバグを…つまり「そんなものを」の理由だが…実はこのバグ、とても「簡単」なのだ。簡単で、なおかつこのパスを通るのはレアケースだった。だからなかなか見つからなかった。かつ、致命的なバグだった。一撃でシステム全体を浮動小数点例外割り込みの無限ループに叩き込む事ができた。
他の人に「カーネルにおける致命的なバグの例」を説明する場合、これほどの好例はめったにない。だから、年に1回か2回、参照したくなる。ところが大事なときに見つからなくなる事が多いのだ。せっかくなので、記録しておこう、とそういうわけ。

では、まずはパッチの内容から。

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/06/14 16:05:28-03:00 marcelo@logos.cnet
# Alexander Nyberg/Andi/Sergey: Fix x86 "clear_cpu()" macro.
#
# Linus's 2.6 changelog:
#
# Fix x86 "clear_cpu()" macro.
#
# We need to clear all exceptions before synchronizing
# with the FPU, since we aren't ready to handle a FP
# exception here and we're getting rid of all FP state.
#
# Special thanks to Alexander Nyberg for reports and
# testing. Alternate patches by Sergey Vlasov and Andi
# Kleen, who both worked on this.
#
# Signed-off-by: Linus Torvalds
#
# include/asm-i386/i387.h
# 2004/06/14 16:04:08-03:00 marcelo@logos.cnet +1 -1
# Alexander Nyberg/Andi/Sergey: Fix x86 "clear_cpu()" macro.
#
diff -Nru a/include/asm-i386/i387.h b/include/asm-i386/i387.h
--- a/include/asm-i386/i387.h 2004-06-16 04:38:26 -07:00
+++ b/include/asm-i386/i387.h 2004-06-16 04:38:26 -07:00
@@ -34,7 +34,7 @@

#define clear_fpu( tsk ) do { \
if ( tsk->flags & PF_USEDFPU ) { \
- asm volatile("fwait"); \
+ asm volatile("fnclex ; fwait"); \
tsk->flags &= ~PF_USEDFPU; \
stts(); \
} \

ほとんどがコメントで、変更点は

asm volatile ("fwait");

という行を

asm volatile ("fnclex; fwait" );

に入れ替えた、と言う所だけ。

このバグは結構間抜けなバグだ。

そもそも、この clear_fpu() というマクロは、割込みハンドルなどの過程で浮動小数点ユニットを使っているプロセスが、コンテキストスイッチを起こしたとか、FPU例外を発生させたとか、そういう割込みハンドラーの中で使われる。

一番簡単な例は FPU例外が発生した場合だろう。浮動小数点計算をしていて、Not a Number(NaN) のような数字が出てしまった、というようにFPU例外が発生すると、
- FPU例外が発生したよんビット
がまず0から1になる。で、これが1になると、浮動小数点例外割り込みが整数演算ユニット側に発生する。これは昔、浮動小数点が 8087 という「CPUの外にあるコプロセッサ」で処理していた頃の名残だ。
一旦例外割り込みが発生すると、「例外ハンドラから制御を戻す」までは FPU例外自身も含めて、もう割り込みは発生しない。例外ハンドラから制御をもどすと、次の割り込みが発生する。この機構をちょっと念頭に置いて欲しい。

FPU例外が発生したら、何らかの処理を行う必要がある場合が多い。例えば、unix の場合は SIGFPE というシグナルを投げなくてはいけない。

しかし、FPU例外割り込みの処理自体は kernel のお仕事である。そこで、まず、この例外を受けた、という事を kernel は受け止め、その上で FPU例外が発生したよんビットを0に戻した後に、ユーザプログラムの SIGFPE が発生した場合のシグナルハンドラーを起動する、必要がある。

上記の赤字の部分を実行するのが、clear_fpu() というマクロ　のはずだったのだが…

FPU例外が発生したよんビットをクリアする命令は fclex, fnclex の2種類の機械語命令だけ。
fwait は「浮動小数点ユニット」と「整数ユニット」の同期を取り直すための機械語命令。

本来であれば　FPU例外が発生したよんビットをクリアする命令　を投げてから、FPUが落ち着くのを待って、ユーザプロセスへと制御を戻す作業を始めるべきなのだが、古いコードはこれをやり忘れていたという事だ。という事は、FPU例外割込みハンドラから戻ろうとしたその瞬間に、再び FPU例外が発生し(だって FPU例外がはっせいしたよんビットは 1 のままだからね)、再び割込みハンドラに戻り…を無限に繰り返す羽目に…

普通、ユーザプログラムを書く人は、FPU例外が発生しまくるような書き方はしない。ややこしい浮動小数点計算の最中に「計算がおかしかったです」と言われても、どうすればいいのやら判らないからだ。しかし、これは「浮動小数点例外が発生しない」のではなく、一瞬にしてわけが判らない状態に陥るため、なにが原因だか判らない、という事だ。多分、多くの人が、正体不明なシステムダウンを経験し、しかし「Linux だし、そんなもんさ」とか「PCが安物だから」とか思っていたのだろう。
特に、このバグは CPU 依存性がある。他の CPU で起こっていないとなれば…安物だから、と思い込んでも不思議ではない。

このため、このバグはなかなか表に出てこなかった。

一旦発生すれば、無限に割込みハンドラを実行し続けるため、もはや復旧不可能なバグでもある。迂回する方法は浮動小数点計算で例外を絶対発生させない事だけ。これは実質不可能だ。

修正ポイントは単純で、判り易い。気が付いてしまえば何という事のないバグだ。

このようなバグが、あといくつ Linux にあるのか、と聞かれても、はっきり言って判らない。判るわけがない。IA32 の浮動小数点命令の果てまでも暗記しているプログラマなど、いまどき世界中を探しても3人もいないだろう。そしてあまりにも単純であるが故に、問題があると感じる者も無く、IA32のインストラクションセットを確認し直す者も無く…ここまですり抜けてきたのだ。

こういう心理的盲目点に存在するバグは、よほどラッキーでない限り発見できない。このバグを犯した人間を、見落としてきた人間を攻める事はできない。見えないものは見えないのだから。

ここまで、判り易く、かつ被害甚大なバグは珍しい。どちらか一方と言うケースはよくあるのだが。
プログラミングの初心者にも理解できる、という意味で、このバグはとても貴重なのだ。

2007年3月12日

Windows で TCP/IP の送信バッファ・受信バッファに残っているデータ量を知る方法

えー、ここで尋ねられたので、一応調べてみようと言う気になったのだが(IE6でうまく表示できないとか教えてもらったし)…残念ながらいい方法は見つかりませんでした。

まず調べ方を説明しましょう。

大抵の場合、Windows もののプログラミング系調査は http://msdn.microsoft.com/ から始めるのがよさそうです。
TCP/IP は Windows では Winsock という名前のはずなので、右上の検索で winsock を検索します。
Winsock Reference という「おい、それだろう…」と言いたくなるようなポイントがあるので、それをクリックします。
で、ここから先は…全探索です。端から端まで読むしかありませぬ。 orz

で、一応調べた結果わかった事は次の通り:

受信バッファにどれぐらいあるか、は「受信バッファから atomic にどれぐらい読み出せるか」という意味だと摩り替えると、ioctlsocket()　と WSAIoctl() のどちらかを使えば出来る。
マニュアルを読む限り、どちらがどちらに比べてよい、という事はなさそう。結局 cmd に FIONREAD を与えると、得られるらしく、ようするに途中から同じルーチンなのではないかと。注に気をつけること。
送信バッファにどれぐらい溜まっているか、を調べる術は無いらしい。少なくとも見つかりませんでした。

この手の調査で一番難しいのはないものを延々さがし続けること。適当な所で諦めるのが肝心だが、実は手段があったりすると調査不足と言われるのが悔しかったりする。

なので、やり方を知っている、もっと簡便な方法があると知っている人の情報があったら、是非教えてください。

2007年3月10日

では object を使ってみよう

と書いてみましょう。さてどうなるか…

うーん。type をいちいち指定しなくてはいけないのは、結構うざったいかもしれない。
あと、枠が表示できていないとか、このままだと横方向のスクロールバーのせいで、縦幅が足りていないとか、やはり縦幅は「include する側」のサイズだとか…いろいろ問題はあるなぁ。一応 XHTML 1.0 に strict に対応しているのはこちらのはずではあるのだが…。

あと、iframe, object 共にそうなのだが、# を使って中間へジャンプさせる形をとると、firefox がそれに引きずられて、ジャンプしてしまう。大抵の場合、引用している側の意図は、表示画面全体をずらすことではないはずなので、これはどうにかして欲しい。

2007年3月9日

IBMを世界的起業にしたワトソンJr. の言葉

帯の顔写真はどーんと柳井さん。これでは何の本やら、誰が書いた本やら良く判らなくなりかねない、そんな本。最近の「Thomas J. Watson 親子関連出版ブーム」の一環なのだろうか。

内容はたったの 136ページ。コロンビア大学院ビジネススクール 1962年春季講義をまとめたものなので、本当にこれは、全部あわせても4時間無かったのではないか、と思われます。

だが、逆に会社を運営する上での「CEOが持つべき大きな指針」というのは、どういうものであるべきか、を勉強するには良い本。量も少ないので、よほどの人でも1週間かかりません。私は3時間でした。

45年前の話なのに、いまだにこの程度の事すら判らない人がお偉いさんの大半を占める、この現状を考える限り、日本の未来はお寒い限りだ。

2007年3月6日

み～つっけたっ

おぉ、ナカムーの blog だ。
Service Science 系の研究をしているのか。

来週の月曜日は、早速
「blogの更新が滞っているのはサービスが悪い」
と突っ込むことにしよう (^o^)。

2007年3月5日

iframe をちょっと使ってみました。

iframe というコマンドを使うと、他の URL を参照する「箱」が作れる。そこで、その実力を見せてもらうべく、ちょいとくら実験だ。

実験の被害者はhttp://www.linux-m32r.org/lxr/http/source/arch/i386/kernel/i387.c?a=i386#L51
という URL。Linux のソースコードが「さくさくっ」と参照できる良いページ。登録されているページが偏っているのが弱点。

という iframe を仕掛けてみる。うりゃっ!

こんな結果が出ました。うーん。「3行」ぴったり表示させるには height の指定をどうすればいいのか、が課題ですな。3em ではちょっと合わないらしい。あと、align="center" がいまいち効果が無い。なにより、このテンプレート、横幅が足りませんね。

でも、GLOBAL や LXR と連動して…という場合、上記のような記述を半自動で作れる仕組みがあると、とても良いかもしれない。Ajax で作れるかもしれないなぁ(というか、自分で作るのは面倒だから、誰か作ってくれないかなぁ…他力本願寺)。

leverage all over the place

金持ち父さんシリーズで、まだ読んでいない本がBookOff においてあったので読むことにした。このシリーズはたまに「はっ」とするような素人向けの説明があるので一応チェックすることにしているのだ。

この本の本当のポイントはレバレッジらしい。つまり 1の作業で、1の結果を得るのではなく、1の作業から10も100も結果を得なさい、ということだ。

お金を得るためのレバレッジと考えるとなかなか思いつかないが、他のものでもよいとなると、なるほど。確かに、世の中、レバレッジを使ったほうが良いことで溢れている。

たとえば、私がたくさん本を読むのもレバレッジの一種だ。
何か新しいことをやる場合、その前に入門書と専門書を最低1冊づつ手に入れるようにしている。で、入門書を必死こいて読む。「物事を始める前に」これをやっておく。たとえ OJT のようなものだとしても、これだけは手を抜かないようにしている。

入門書を読んだからと言って、これからやる仕事のコツがつかめるわけではない。しかし、何の予備知識も無い、0の状態からスタートするわけでもない。全体が100だとするならば、この努力で 1 か 2 辺りからスタートできる。周りが100を学ぶときに、自分は99とか98で済む、と言うのは心理的にすごく楽になる。結果、狭視野に陥りにくくなる。で、その分少しだけほかの事に気がつきやすくなる。

また、専門書はその分野についてのエッセンスが書いてある。一般に経験だけから全てを導き出そうとすると、S/N 比が悪すぎる。だから他の人が S/N 比を改善し、情報を集中させた専門書は、理解速度を上げるのに役立つ。

それだけではない。そもそも知識を全部暗記するのは不可能だ。知っていることを全部書き出すのは手間がかかりすぎる(数回、雑誌に記事を書いただけでしみじみ思うもの)。他の人がエッセンスを書き出しておいてくれたものを手元に置いて、必要に応じて参照するのは、とても有効なことだ。

これら全てが、情報収集に関するレバレッジである。

こう考えると、金持ちになるためという目的のためにはレバレッジを使っていないだけで、人間はレバレッジを結構使っている。「その発想を金に対しても使え」と言うのはある意味、妥当だ。

実は、fj の教祖様の蔵書/既読書@GeoCities もレバレッジだ。本をある程度読むと、「役に立たない本」とか「時代遅れな本」が判るようになる。が、さらにしばらくすると「どの本が役に立たなかったのか」を忘れてしまう。そこで、自分の脳みそではなく、外部記憶にそれらの情報を記録することになる。

検索性などを考えると、紙と鉛筆よりも計算機上に記録するのが正しいのは間違いない。しかし、手元のローカルマシンにだけその情報を置いてしまうと、今度はマシンがクラッシュしたときにデータを全滅させてしまう恐れが出てくる。本屋へ行くときに持ち歩きたい、という要望が、マシンクラッシュの確率をさらに上げる。

ならば、他の人にも公開して、リモートからもアクセスできるようにすれば、携帯端末からでもアクセスでき、マシンクラッシュの確率も下がり、バックアップも世界中に取れている、と一石三鳥だ。しかも、検索はgoogleの計算機パワーを使える。ちょいと、他の人のお役に立てるかもしれない状態にするだけでこれこの通り、自分にとってとっても便利な状態が発生する。1が2,3,4 倍ぐらいにはなってくれている。

ようするに、お金がたくさん欲しかったら、お金に関しても同じような事をしなさい、とまぁようするにそういうことなんだな、と理解した。

2007年3月2日

Google誕生

いや、これは面白かった。
出版日は2006年6月1日で、実際結構前に読み終わってたんだけど、再度読んでしまいました。

一応、今はまだ既読・コンピューターと言う分類にしてあるのですが、果たしてそれが本当に正しいのか、正直わかりません。微妙にもれ出てくる、Googleエンジンの他のサーチエンジンとの違いの所だけを考えるとコンピューターという分類なんでしょう。

でも、Google最大の特徴は、「研究室を運営しているかのごとく」行われているその運営方針でしょう。この会社、社員に対して要求するレベルがとんでもなく高い代わりに、提供してくれるサービスもとんでもなく高い。
『ちゃんと環境を用意してあげるから、インターネットに奉仕する、と言う形で Google に奉仕しなさい』
というのは、広告を主たる収入源にしている Google にとって、大正解な戦略。

ここまで正解かつ大胆な会社運営方針を思いつくだけでもえらいと思いますが、はて、正解が判っていても、これを実行できる人が他にいるだろうか?? Microsoft をも含めて、ね。

…まぁ、できれば実行できる人になりたいやね。そのためにも、まずは大それた収入源を作らなくては。

業務連絡

えー、Alicia! Alicia!! Alicia!!! は、実はある実験のためにちょっと凝ってみたものです。というわけで、凝った結果の報告。

見ての通り、一応ソースコードを表示できます。テンプレートに手を加え、HTMLを直接編集する必要がありましたが。

テンプレートへの変更は次の通り。

まずは色の定義を2つ追加しました。ソースコードの文字本体の色は変更するつもりは無かったので、背景色と、囲み枠の色だけです。

次に、ソースコード用のクラスを用意しました。これは /* Posts 行で始まる、投稿用クラスセットの末尾に追加したものです。

span.post-sourcecode {
 background-color: $mainSourceBgColor;
 border:           1px solid $mainSourceBorderColor;
}
div.post-sourcecode {
 margin: .25em .25em;
 background-color: $mainSourceBgColor;
 border:           1px solid $mainSourceBorderColor;
}
pre.post-sourcecode {
 margin: .25em .25em;
 background-color: $mainSourceBgColor;
 border:           1px solid $mainSourceBorderColor;
}

インデントの事を考えると、divはほとんど活躍の機会はないと思います。span は行の中にコードをいれたい時専用ですね。

で、その上で、

もし、あなたが Term::ReadLine::Perl を使って何かしたければ、<div class="post-sourcecode">$readline = new Term::ReadLine::Perl 'hoge';</div>とすればよい。

や、

あとは<span class="post-sourcecode"> $readline->readline(); </span>のようにメソッドを呼べばよい。

あるいは、

次のパッチを当てればよい:<pre class="post-sourcecode">diff -ur Alicia-1.1.4/lib/Alicia/ReadLine.pm Alicia-1.1.4-fix/lib/Alicia/ReadLine.pm
--- Alicia-1.1.4/lib/Alicia/ReadLine.pm 2005-03-03 13:47:00.000000000 +0900
+++ Alicia-1.1.4-fix/lib/Alicia/ReadLine.pm 2007-03-02 00:17:21.238375000 +0900
@@ -14,12 +14,13 @@
package Alicia::ReadLine;
（中略）
-    my $self = new Term::ReadLine;
+    my $self = new Term::ReadLine::Gnu $class;
  return bless $self;
}
</pre>

ようするに Term::ReadLine::Gnu を強要してしまえばよいのだ。

のように HTML レベルで編集すれば、Blogger でもソースコードを掲載することはできます。

ただし、あまりお勧めではありません。

テンプレートをゴリゴリ弄り回すと言うことは、何かの拍子にテンプレートモデルが大幅に変更になると、作りこみが全部消えてしまうのだ。そりゃ、どこかに保存して、再度 apply すればいいんだろうし、それは全部のコードを弄り回すのに比べれば楽なのだろうが…。それでも結構辛いだろう。
ソースコードの中の不等号を全部置き換えて回るのは手作業になる。これは思った以上に辛い。いや、Alicia のソースの場合はまだいいのだけれど、上記の例の場合、タグの山なので…。

というわけで、他もどっこいどっこいだと判ったら Blogger を使えばいいと思う。逆に、ソースコードを掲載するのに都合のよい Blog が判ったら教えてくれぃ。私もソースコードものはそちらに書くことにするから。

2007年3月1日

Alicia! Alicia!! Alicia!!!

Alicia というのは、この場合 Uniadex 社さんが開発した crash のフロントエンドソフトだ。
最新版は 1.1.4で、sourceforge に登録されたのが「2006-3-14」という実に『年度末』を意識したいいタイミングで更新が止まってしまっている。頼むよ…。

おおよそ1年経つと他のソフトはイロイロ進化していくわけで、そういう意味ではIPAのお金で開発するのはいいがその後の金策の目処が立たない場合、お金以上に人の努力が風化してしまうという、実にもったいない代物である。

その中でも最ももったいないのが、

このプログラムは perl の Term::ReadLine::Perl を前提にしている

という点だったりする。

ご存知の通り、perl は 5になってからオブジェクト指向もどきな記述も許すようになった。この事実と CPAN の発展のおかげで、perl には山のような…そう、文字通り山のようなライブラリセットがある。その中に、readline ライブラリを perl で実装する、というものがある。

Term::ReadLine::Stub というライブラリがスタブライブラリだ。デフォルトでもこいつは存在するが、コイツ自身はスタブなので本当の本当に最小限度の事しかしてくれない。オブジェクト指向と言った通り、もし独自の Term::ReadLine もどきのライブラリが作りたければ、Term::ReadLine::HogeHoge という名前で作ればよい。Term::ReadLine とメソッドなどの形式をきっちりあわせておけば、Term::ReadLine を使うように作られたプログラムは、全部あなたの Term::ReadLine::HogeHoge でも動くことになる。

で、大雑把に言って、HogeHoge の部分には今、2種類の実装がある。Term::ReadLine::Perl と Term::ReadLine::Gnu の2つだ。

Term::ReadLine::Perl は、結構昔からある実装で、deprecated扱いである。ようするに、今これをベースに物を作ってもうまく動かないのだ。

Term::ReadLine::Gnu は、gnu readline ライブラリのフロントエンド perl ライブラリで、これを導入すると、Term::ReadLine のデフォルトが stub から Gnu に完全に override するという気合の入った代物だ。

さて。通常のオブジェクト指向であれば、Term::ReadLine::Perl と Term::ReadLine::Gnu は同居できる。もし、あなたが Term::ReadLine::Perl を使って何かしたければ、

$readline = new Term::ReadLine::Perl 'hoge';

とすればよい。Term::ReadLine::Gnu を指定する必要があるなら、

$readline = new Term::ReadLine::Gnu 'hoge';

になるし、どれでもいいや、というなら、

$readline = new Term::Readline 'hoge;

と初期化すればよい。あとは $readline->readline(); のようにメソッドを呼べばよい。

しかし、相手は perl。そうは問屋がおろさない。

問題は、Term::ReadLine::Perl は deprecated な理由。実は、Term::ReadLine::Gnu と Term::ReadLine::Perl のインストール順序と、利用するコードによっては、 $readline-> で参照しているはずの関数の一部が、Term::ReadLine::Gnu のもののままになっており、そいつが必要なメソッドを Term::ReadLine::Perl が実装していないため、実行時エラーを吐いて止まってしまうのだ。Aliciaにはどうやらこのような使い方をしている部分があるらしい。そして、Term::ReadLine::Perl しかインストールしていない環境でしかテストしていないらしいのだ。

厄介なのは、

$readline = new Term::ReadLine 'hoge';

のようにデフォルト利用に設定した場合、実は何が使われるかはインストール順序依存だ、という点にもある。環境によって、Alicia は動いたり動かなかったりするのだ。

実は直す方法は判っている。次のパッチを当てればよい:

diff -ur Alicia-1.1.4/lib/Alicia/ReadLine.pm Alicia-1.1.4-fix/lib/Alicia/ReadLine.pm
--- Alicia-1.1.4/lib/Alicia/ReadLine.pm 2005-03-03 13:47:00.000000000 +0900
+++ Alicia-1.1.4-fix/lib/Alicia/ReadLine.pm 2007-03-02 00:17:21.238375000 +0900
@@ -14,12 +14,13 @@
 package Alicia::ReadLine;
 
 use Term::ReadLine;
+use Term::ReadLine::Gnu;
 
 @ISA = qw (Term::ReadLine);
 
 sub new {
     my $class = shift;
-    my $self = new Term::ReadLine;
+    my $self = new Term::ReadLine::Gnu $class;
     return bless $self;
 }

ようするに Term::ReadLine::Gnu を強要してしまえばよいのだ。

取り合えず、この方法で Alicia は動く。
問題は、Alicia を作った人たちが、Term::ReadLine::Perl を使ったと言いながら、Term::ReadLine で $self を作り上げている点だ。彼らは、Term::ReadLine::Perl の何に依存してコードを作ったのだろう? そこを踏むにはどうすればいいのだろう??
これが判らないと、テストもデバッグも出来ない…。

Solaris10 telnetd 脆弱性を突いた worm 発生

「パターン青! 使徒です!!」

というわけでは無いだろうが、Vulnerability Note VU#881872(Sunの管理番号では #102802)を利用した worm が発生したらしい。

Solaris in.telnetd worm seen in the wild + inoculation script

このwormの攻撃対象は x86 と Sparc の両方のプラットホームだそうだ。kshを使っているらしい。

うーむ。いまどきどうしてこんなバグが…という気もするが、やはり弱点が露呈すると worm を作る人が出て、しかもそれが実際に効果を上げる事が出来る、という事は、世の中の多くの人が、いかにセキュリティを甘く見ているか、いかにセキュリティ被害コストを甘く見積もっているか、の表れでは無いだろうか?

それとも侵入される程度であれば、予定通りで問題は無い、という事なのだろうか?
root権限ごと持っていかれているのに???その割には、「口うるさい」のも事実だよね?

頼むから口で言っている要求レベルと実際にお財布から出すコストで実装できるレベルが乖離しまくっている状態を認識できないような人・組織・会社・政府に IT インフラ実装のための予算を与えないで欲しいなぁ…。