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 側が勝手にタグと勘違いするらしい。で、これを &lt;&gt; と書き直すと、今度は prettyprint が判らなくなるらしい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


この調子だと:

受験ハック

とか:

結婚ハック

とか:

お葬式ハック

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

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

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

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

ドキドキの向こう側…

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

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


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

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

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


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

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

p.332 だと

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

とある。

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


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

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


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


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

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

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

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

英語版は確か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の資料庫からの資料も参照しているので、「息子がこう感じていた頃、父親はこう感じていた」的な見方ができて面白いのだが、大半が『感情的にぶつかり合っている』のを家族が周りでおろおろ見ている、という図に落ち着くのが…。

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

円/ドル レート

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

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

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

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

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のインストラクションセットを確認し直す者も無く…ここまですり抜けてきたのだ。

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


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

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

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

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

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

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

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

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

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

では object を使ってみよう

<object type="text/html" data="http://www.linux-m32r.org/lxr/http/source/arch/i386/kernel/i387.c?a=i386#L51"
style="width:90%;height:3em; align:center;" scrolling="no" marginwidth="0" marginheight="0" frameborder="1" ></object>

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



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

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

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

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

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

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

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

み～つっけたっ

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

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