January 2006

Jockeyの論文を斜め読みしたので簡単に


  • 用途はデバッグ。特に以下の3点はいままでデバッグがめんどかったのでメインターゲット

    • 動作が非決定的であり、結果が毎回変わるプログラム

    • 長時間動くプログラム、長すぎて何回も再試行できない

    • distribeted program. 1台だけデバッガくっつけたら動作が変わってしまうようなもの



  • 以下の制約があるよん

    • mmapやファイルアクセスが可能だと仮定しているよん

    • 共有メモリを用いた他プロセスとの暗黙の通信はcaptureできないよん

    • kernel thread を用いた pthread実装をつかうcontext switchのタイミングが制御できないので再生時に前回と違う結果になったりしてうまくいかないよん




  • 実装について

    • libcのシステムコールの入り口を書き換えてlibjockey.soのそれを呼び出すように(テキストセグメントを)書き換えちゃうよん(time, rscvfrom, selectなど)

    • rdtsc命令もcaptureするようにメモリ上のプログラムを改変しちゃうよん

    • 各システムコールで再生時に同じ結果を返せるように結果をlogに保存するとともに、途中からの再生をサポートすべくcheckpointを作成するよん

    • rdtscパッチを考えると、パッチ動作には時間がかかる(平均約350ミリ秒だそうな)のでオブジェクト毎にどこを書き換えればいいのかの情報をキャッシュするよん

    • Exec Shield はOFFにしないと動かないよん

    • 非同期シグナルは以下のようにとりあつかうよん
      まず、libjockey.so がシグナルを補足、内部のシグナル受け取ったよフラグを立てるとともに、シグナルナンバー、CPUレジスタを保存
      次のシステムコールが呼ばれたときに、フラグが立っているのでユーザーアプリのシグナルハンドラをアップコール。
      ・・・なんでその場でアップコールしちゃいけないんだっけ?
    • mmap I/Oの追跡
      内緒でぜんぶ read onlyにしておいて、SIGSEGVするたびにwritableにし、また次のシステムコールの入り口でread onlyに書き換える。するとどのページがいつupdateされたか追跡できる。だそーな

    • ユーザー定義のある関数が呼ばれたときに呼ばれるHook関数を挿入できるよん、そのやり方は(ここ注目!)
      現在メモリにmapされているすべてのshared objectにnm、publicな関数のアドレスを調べる。
      そのアドレスを決めうってリンクするリンカスクリプトを動的に生成、スタティックリンカ(ld)にかける。
      それを適当なアドレス空間にmmapし、ユーザーHook関数を呼び出すようにHook先関数の先頭部分を書き換え。
      うーん、強引すぎて感動に屁が出そう




  • おいらの疑問

    • checkpointをどういう形式で保存しているのかよく分からなかった

    • パッチ位置のキャッシュだが、オブジェクトがバージョンアップしちゃったらどうしたらいいのかしら?





追記: このソフトはバックエンドにlibdasmというディスアセンブラを使っているようだ。たしかにx86のopcodeの解読なんていちいち作りたくないわな。
結構使いやすそうなんで、気になっているのだがライセンスがよく分からんぞー


4a529c3c.jpg


このエントリーをはてなブックマークに追加

大好きなPeoplewareを読み直している。デマルコはどれも好きなのだが。

その中でも特に大好きな一節を紹介したい


私は病床から足を引きずってオフィスへ行き、顧客用の不安定なシステムを立て直そうとしていた。
シャロンは倒れそうになった私を支えてくれちょっと姿を消したかと思うと暖かいスープをもってきて私を元気付けてくれた。
私は聞いた「管理業務が山ほどあるのに、どうしてこんなことまで出来るんですか?」
シャロンはにこやかな笑顔で答えた「これが管理というものよ」


私が実業務でボンクラ管理職にいつもイライラさせられ、時には痛い目にあわされてもマネージメントに対して深い敬意を払い続けている、そのルーツはここにある。




このエントリーをはてなブックマークに追加

読了。
ハイテクビジネスの教科書としてこれほど有名な本もないと思うので月並みな書評はかかない。

この本が、支持され続けているのは切り口の鋭さとシンプルで分かりやすい結論があるからだと思う。あーだこーだと長々と書き連ねたあげくに、結局ケースバイケースです。などとお茶を濁すようなビジネス書が氾濫している中でこれは貴重なことだと思う。
しかしながら、その切り口の鋭さを得るためにこの本は書いてないところでいくつか仮定を置いてある。

・その分野はブランド力が弱く、顧客は製品を機能や値段で選んでおり、ファッションとしては見ていない。
・製品は容易に代替可能なものであり、他社製品への乗り換えにあたって新たな学習を特に必要としない。
・製品の使用方法は顧客間で独立しており、顧客は他の顧客と同一製品を選ぶメリットがほぼ、あるいはまったく存在しない


もっと具体的に書くと

・昔RISCという言葉がはやっていた頃IntelのCPUはRISCチップより大幅に遅かったが、Intelは牙城を守った。
顧客は「速度」に一番のプレミアムを支払ったが、過去のプログラムが動かない製品は同一カテゴリとは
みなされなかった。
・Macは使いやすさでWindowsを上回るとしばしば評されながら、Windowsのシェアをぜんぜん奪えていない
・ソニーと松下が同じ機能、同じ性能の製品を発売したらソニー製品のほうが1割ほど高い値段がつく。
ソニーは合コンで見せびらかせるが、松下はこうはいかない。
(最近はちょっと事情が違うようだけれども)


つまり、僕にはハイテク企業の利益の源泉は代替不可能なところ、乗り換えにものすごく(コスト的にまたは心理的に)抵抗がある状況に「ゲームのルールを自分に有利なように構築してしまっている」所だと思っている。
だから、特に米国では2位以下の企業から標準化の大合唱が始まることが多い。
技術経営の観点からはこういうゲームルールの構築するのが120点の答えで、変わっていくルールにうまく追従するのは80点の答えであろう。
その辺をすっとばして(もちろん中途半端に書くと収拾がつかなくなるのでこの本の切り捨て方は正しい)ある局所的なシーンを解説している本である。という点を忘れなければこの本は本当にすばらしいと思う


このエントリーをはてなブックマークに追加

SEO対策ページを見ていたらSEO対策にはH1タグが重要だそうな。

H1は流石に文字が大きくなりすぎるので、記事タイトルをH3あたりで囲んでみる。
今のところ、体感的には何も変わらない。
このエントリーをはてなブックマークに追加

ちょっと遅いが広報の転載

Fedora ProjectのWarren Togamiどんが来日するのでセミナーするんだそうな。お暇な人はどうでっか

http://jla.linux.or.jp/announce/20060106/1.html
このエントリーをはてなブックマークに追加

このページの訪問者様のリンクから以下のようなページを発見。こういう意外な出会いを体験してしまうのがblogの醍醐味だ。

■ソルトクリスタルランプ・岩塩ランプとは?
ソルトクリスタルランプ、ソルトランプ、岩塩ランプと呼ばれるこの不思議なランプ、文字どおり塩で出来たランプなんです。
それもただの塩ではなく、ヒマラヤ山脈の麓、地下1,500mから採掘した2億5千万年前の天然の岩塩結晶です。
2億5千万年前?
それは恐竜の白亜紀よりも遥か以前、まだ世界がパンゲアと呼ばれるひとつの超大陸だった頃・・・。


やばい。欲し過ぎる!
2億5千万年前ですよ。パンゲアですよ。しかもヒカリモノ。狙ってるとしか思えませんよね

http://saltlamp.jp/

あ、僕は買ってないし、広告でもないので買ってみてハズレだったとしても責任もてません。あしからず・・
このエントリーをはてなブックマークに追加

SEO対策をまとめたページを発見。ブックマーク

http://www.su-jine.com/
このエントリーをはてなブックマークに追加

いつも参考にさせていただいているいやなブログ様より。
Jockeyというソフトでプログラムの実行を記録、再生するという記事。

ポイントはカーネルパッチを必要としない。というあたりではなかろうか。従来はこういうことをしようと思ったらデバッグ用特殊カーネルが必要で、実システムにんなもんインストールできるかーい。という感じであった。

プログラムだけでなく、論文も存在するところがすばらしい。

主眼はデバッグであり、プログラムの凍結・解凍はあまり考えていないようだが十分参考になる。

http://namazu.org/~satoru/blog/archives/000098.html


4a529c3c.jpg


このエントリーをはてなブックマークに追加

大好きなblogである、「Life is beautiful」様 にて公開されているこれまた大好きなblogミニアプリの「今日のひとこと」をうちのサイトにも掲載させていただくことにした。

ソフトウェアのUIには、こういうちょっと触って「おもしろい」と思わせる「遊び」が必要だと再度思わせてくれた偉大なソフトに感謝をこめて。
このエントリーをはてなブックマークに追加

なかば興味本位でgoogleとAmazonのアフィリエイトに参加を決意する。

ちょっとやってみた感想だとうちのような小規模サイトの場合、googleよりもAmazonのほうが管理人ですら思わず欲しくなってしまうオススメ広告をチョイスしてくれるようだ。

これはピックアップ元の母集団の大きさが全然違うのが大きい。amazonは書籍全般を母集団としているのでなにかしらマッチングする対象を探せるがgoogleの特に日本国内でのGoogle AdSenseは、まだ管理人がわくわくを感じる広告をピックアップできるほどには母集団が大きくないと感じる。
(むしろ現状ではユーザー立場からすると不快度のほうが大きいのではないかとすらGoogle AdSenseには感じてしまう)

逆にAmazonのピックアップは自分自身がどんどん本が欲しくなってしまって逆につらい。
むしろAmazonの株自体が買いたくなってしまった。

数年前までは検索分野ではGoogleが独壇場だったはずだが、いつのまに差はずいぶんと縮められてしまったみたいだ。
このエントリーをはてなブックマークに追加

↑このページのトップヘ