2006年05月
2006年05月29日一週間ほど休暇で自宅を留守にしていたら、 運悪くちょうど半ばあたりで自宅の Linux サーバ (二台ある GCD ゲートウェイのうちの片方) がハングしてしまった。 きっかけは毎晩ハードディスの内容をバックアップするために動かしている rsync だったので、 メモリ不足 ? かなにかの原因でカーネルのバグを引き当ててしまったのか?
安定版でないカーネルを使っていて再びハングする危険もあるので、
早急にバージョンアップが必要なのだが、
その前に新しいカーネルで GV-MVP/RX2W を動かせるようにしないと... (^^;)
# ぱ研を参考にさせてもらっています (_O_)
GCD のゲートウェイは VRRP で二重化してあるので、
片方がハングしても問題無いのではあるが、
手動リセットするまでハングしっぱなしというのでは、
留守の期間が長いと二台ともハングする可能性を否定できない。
# UUCP スプールなど二重化されていないものもあるので、
全く問題が無いというわけでもない
そこでハングしてもなるべく自動的に復帰できるように ウォッチドッグ タイマ (Watchdog Timer) を仕掛けることにした。 つまり一定期間内にタイマがリセットされなければ、 ハングしたと見なして問答無用でカーネルを落とす仕掛けである。
ソフトウェアにどんなトラブルが起きても確実に再起動を行なわせるには、 ハードウェアで物理的にリセット スイッチを押すハードウェアを用いるのが 一番であるが、まずはお手軽にソフトウェア版を利用してみることにした。 ソフトウェアによるウォッチドッグ タイマの場合、 カーネル パニックが起きると当然機能しなくなるわけだから、 パニック時は自動的に再起動するように設定しておく必要がある。 rc.local 等で、
echo 60 > /proc/sys/kernel/panic echo 1 > /proc/sys/kernel/panic_on_oops
を行なっておけば、パニック時は 60秒で再起動するようになる。
次に、ソフトウェア版ウォッチドッグ モジュール (softdog) をインストールする。 softdog.ko を /lib/modules/current 以下に置き、 /etc/modprobe.conf に以下の行を追加するだけ。
alias char-major-10-130 softdog options softdog soft_margin=3600
ウォッチドッグ タイマというと、 普通は 60秒くらいに設定しておくものだとは思うが、 自宅サーバの場合、一時間くらいハング状態が続いてもそんなに困らない ;) のと、 あまりタイマの間隔が短すぎると、不用意に再起動してしまう恐れもあるので、 3600秒 (一時間) に設定している。 つまり一時間以内にタイマをリセットしないと、自動再起動が行なわれる。
後は適当な方法で、 /dev/watchdog に適当な文字 (ただし「V」を除く) を書込むだけである。 例えば、定期的に実行される sh スクリプトに、
echo "@" > /dev/watchdog
という行を追加しておくだけでよい。
Linux カーネルのドキュメント: linux/Documentation/watchdog/watchdog.txt には、
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
int main(int argc, const char *argv[])
{
int fd=open("/dev/watchdog",O_WRONLY);
if(fd==-1)
{
perror("watchdog");
exit(1);
}
while(1)
{
write(fd,"\0",1);
fsync(fd);
sleep(10);
}
}
というサンプルが載っているが、タイマをリセットするプログラムを 動かしっぱなしにする方法だと、 ハングの仕方によってはこのプログラムが動き続ける (つまり自動再起動が行なわれない) 危険がある。 私の自宅サーバの場合は、たとえカーネルが生きていても、 リモートから ssh ログイン出来ない状態なら使い物にならないわけで、 外部から ssh ログイン出来る場合のみタイマのリセットが行なわれるようにした。 つまり、外部から
ssh server "echo @ > /dev/watchdog"
に相当することを定期的に (一時間以内の間隔で) 行なえばよい。 この場合、/dev/watchdog に文字を出力する都度、 /dev/watchdog をクローズすることになり、
SoftDog: Unexpected close, not stopping watchdog!
というメッセージが syslog に出力されるので、 果たしてきちんとタイマのリセットが行なわれているのか不安になるが、 softdog モジュールのソースを見ると、 このメッセージが出力される場合は常に 「softdog_keepalive()」呼び出しが行なわれているので問題ない。
2006年05月22日「成長する秘訣は、 今の仕事を捨てて自分を変えること」に トラックバックを頂いた。 曰く:
ものの考え方にはストック…積み重ねにより大きな利益を得るっていうのもあって、 ストック、フローのどちらをよしとするかはケースバイケースなのでしょうが、 今の時代はフロー的なことが求められるのですかね。
...
ただ、エンジニア稼業というのはスキルの蓄積が実績として重要視される ストックな生き方を要求されることも多いかな。
蓄積には、ストックが増える積み重ねと、 増えない積み重ねがあるような気がしている。 ストックが増えるのであれば蓄積は重要だが、 ストックが増えなくなってきた仕事は捨てることも検討すべきだと思う。
そうでないと、 「これだけいろいろ経験を積んでスキルも蓄えたのだから、 当然評価されてしかるべきだ」という思考停止状態に陥ってしまう。 事実、面接で長大な職務経歴書を提示して、 一つ一つ説明して下さるかたがいらっしゃるが、 そんなものよりたった一つの深い経験の方が重要なこともあるのだ。
「ストック、フローのどちらをよしとするか」という話にしてしまうと、 当然重要なのはストックで、フローはそのオマケに過ぎない、 ということになってしまうが、 そういう問題ではない気がする。 ストックが大事なのは「エンジニア稼業」に限らず、 どんな職種でも同じなのではなかろうか。
2006年05月17日CTO日記に書いた 「断片的な知識と体系的な知識」を、沢山の方々に読んで頂けた。
この季節、新卒(見込み)の学生さんを数多く面接してきたのですが、 新卒の段階で既に とてつもなく大きな差がついていることに改めて驚かされました。
今後大きく成長する可能性が感じられる人と、 早くも既に成長の限界が見えてしまっていて、 可能性がほとんど感じられない人、という点では、 もう既に逆転不可能とさえ思えるような大差がついてしまっています。
可能性が感じられる人、というのはつまり、 自分が何をしたいか明確に分かっていて、 かつその分野の体系的な知識を身につけている人たちです。 現時点ではそんなに多くを習得しているわけではないにせよ、 体系全体を理解していますから、自分がどこまで知っていて、 未知の領域がどのくらいあるか、感覚でつかんでいます。
じゃ、オマエは学生の時どうだったんだ、という声が聞こえてきそうなので、 私の学生生活を振り返ってみる。 コンピュータの分野が好きだと思ったのは中学一年の時で、 体系的な知識を学んだのは大学の専門課程に進んでからである。
私が初めてコンピュータに触れたのは、中学一年生の終わり頃である。 「マイコン部」なるものがあって、 3台のCommodore PET 2001を 20人以上の部員で使っていた。 しかも「部活動」は週一回 50分ほどだったと記憶しているので、 PET 2001 に触れるのは、二週間に一度、25分だけ、 しかも二人で一台を使う形だった。 最初のうちは BASIC を使って簡単なゲームなどを書いていたが、 6502 のインストラクションセットをどこからか見つけてきて (どこで見つけたのだろう？ 当時はその手の資料を中学生が見つけることは、かなり難しかったはず)、 ハンドアセンブルしたコードを BASIC の poke 文でメモリに書いて 実行させて遊んだりした。
初めて BASIC の入門書を読んだとき、 将来プログラミングを仕事にできたらどんなにいいだろう、 と思ったのを今でもはっきり覚えている。 今からは想像もつかないが、 1978年当時の中学生にとって、 一人一台マイコン (当時の呼び方 ;) を占有できるなんてことは、 とうていかなわない夢だった。
高校になってようやく MZ-80K2E を購入した。 日経Linuxに執筆した連載の枕から引用:
私が最初に購入したコンピュータは， シャープのMZ-80Kシリーズの最後の機種K2Eでした。 RAMは32Kバイト，CPUはZilog Z-80 2MHzで， BASICインタプリタをROMではなく， カセット・テープから読み込む方式であるため， BASIC以外の言語への対応が容易という， 当時としては画期的なパソコンでした。 BASICライクなアセンブラBASE-80を使って， ゲームやモニターを作っていたことを思い出します。 その後，CP/Mを移植するためにBIOSを記述する際にも， BASE-80を使いました。
高校時代は、マイコンのハードウェアに興味を持ち、 MZ-80K2Eのプリント基板の配線を目で追って回路図を起こし、 それをもとに Programmable Character Generator や Z80 DMA を追加するなどの改造を行なった。 また、 コンピュータ以外の分野では、 物理や哲学に興味を持ち、 1年に百冊以上読む、という目標を立てて 手当たり次第に読書したこともある。
コンピュータにのめり込んだ高校時代だったため、 大学に進むとき、物理, 数学, 哲学などの道に進むことも (一瞬 ;) 考えたのであるが、 コンピュータを学んだといっても所詮は独学に過ぎず、 まだまだ学ぶことがあるはずと思い直し、情報工学科に入学した。
1回生のときは、Z-80 を使ったコンピュータの手作りに熱中した。 ユニバーサル基板を何枚か使って、 それぞれ CPU ボード、I/O ボード、DRAM ボード、などを順に作り、 MZ-80K2E をキャラクタ端末にして CP/M を走らせた。 2回生のとき、ソフトウェアハウスでアルバイトするようになり、 MacVJE などを開発した。 私にとって初めての、 まとまった量のプログラミング (C 言語で 5万行くらい) 体験だった。
このあたりまではあくまで独学であり、 断片的な知識の寄せ集めである。 もっとも、現在のようなインターネットなどなかったから、 全て (数少ない) 専門書を読みあさって仕入れた知識であり、 Web ページで得られる知識よりは、マシだったかもしれない。 当時のコンピュータ関係の専門書は、 大型書店 (大阪梅田の紀伊國屋や旭屋など) にしかなく、 それも数えるほどしかなかった代わり、 ほとんどがマトモな本だった。
3回生になって初めて情報処理の基礎を学んだ。 今まで経験則で回路図を設計していたのが、 カルノー図を使うとシステマチックに最適な回路を設計できる、 ということを学んで感動し、 独学の限界を思い知った。 なにせ、それまではコンピュータの設計というと 数週間かけて行なうものだと思っていたのに、 教科書で説明されている方法だと数時間しかかからないのだ。 私が初めて大海を垣間見た瞬間かもしれない。 そのとき読んだ教科書がこれ:
Switching and Finite Automata Theory
Zvi Kohavi
McGraw-Hill Education ; ISBN: 0070993874 ; (1979/03/01)
ボロボロになるまで読んだ (まあ、もともと製本が粗末というのもあるが ;)。
2006年05月15日CTO日記のほうに、 興味深いコメントを頂いた。 質問者のかたは、 こちらの日記も読んで頂いているようなので、 こちらで続きを書こうと思う。 「分からない時は、『分からない』と言おう」で書いた、 技術者がスキルアップするには、 分からないことがあるときは臆せず質問できる度胸こそ必要、という 私の考えに対するコメントであるが、曰く、
ここで言われている『分からない』という言葉の中には 「知らない」と「理解できない」の二つの意味が含まれているということです。
「知らない」ことについては、（自分を含めて）みんなが知らないことなのか、 自分だけが知らないのかすら判断できないから なかなか質問ができないのだと思います。 聞いた内容によっては(たとえ説明したとしても) そもそもその場で話している内容はまったく分かってないんだな、 と思われたりします。聞くのは危険だと思います。
「理解できない」ことについては聞いた内容について 自分の中で消化できないわけなので、 恥ずかしがらずに質問できるような人になれたり、 環境ができればいいと思います。
「知らない」ということと「理解できない」ということは確かに違う。 私が書いたのは、「理解できない」ということについてであって、 「知らない」ということについては言及していなかった。 「理解できない」ことについては、「恥ずかしがらずに質問できるような人」に なれたらいい、と書かれているので、私と同意見のようだ。
ところが、「知らない」ことに対する考え方は私と全く違うようだ。 この質問者のかたは、「理解できない」より「知らない」ことの方が恥ずかしい、 という感覚のようだが、 私の感覚は全く逆である。 つまり、「知らない」ことは全く恥ずかしいことではない、と私は思う。 だからこそ、「知らない」ことについてはあえて言及していなかった。
「知らない」ということは、たまたまそのことについて 知る機会がなかった、というだけのことである。 誰でも最初は初めてである。 今がその初めての機会であるなら、さくっと質問して 知ればいいだけのことであろう。 どうして今まで知る機会がなかったことが恥ずかしいのであろうか？
「当然知っておくべきこと」だから？
では、なぜそれを「当然」と思うのか？
あたかも、どこかの誰かが決めた、
「技術者ならば常識」というのがあって、
それを知らないのは技術者として失格、とでも言いたいのだろうか？
全くもって馬鹿げている。 たとえその人が「常識」を知らなかったとしても、 素晴らしい能力を持っているかもしれないではないか。 知識の多寡で技術者の能力を推し量ることなど無意味である。 仮に、「常識」を知らないことを理由に馬鹿にする人がいるのであれば、 所詮そのレベルの技術者なのであろう、相手にする必要はない。
一方で、「理解できない」ということは、場合によっては恥ずかしいことである。 もしかすると、質問したことによって、 自身の理解の限界、あるいは自身の理解の速度の遅さを 思い知ることになるかもしれない。 その限界があまり高いレベルでない場合は、 つまり平均的な技術者がすぐ理解できることが、 自分にはすぐには理解できないのだとしたら、 その分野は自分には向いていないということになるだろう。
いままでそのことに気付かなかったのは恥ずかしいことであるが、 なにごとも遅すぎるということはない、 その分野はあきらめて、自分の得意な分野に集中すれば良いだけである。
2006年05月13日今までの自分を振り返ってみると、 ずいぶんいろんな仕事を捨ててきた。 一番大きかったのはもちろん大企業の研究所での研究生活を辞めて、 (株)ケイ・ラボラトリー (KLab の当時の社名) の創業に参加したことだが、 その後も、
- ケータイ上の Javaアプリの開発
- サーバ側の Webアプリケーションの開発
- クラスタリングサーバの構築・運用 (後の DSAS)
- そして KLabセキュリティ(株) への注力
と、どんどん仕事を替えてきた。 部下が成長してきて、私の代わりがつとまるようになったら、 私はもうその仕事はやらない。全てその部下に任せてしまう。 なかなか思う通りにいかないことも多いが、 他の人ができる仕事は自分ではやらない、という原則を自身に課してきた。
同じ仕事をやり続ければ次第に要領が分かってきて、 よりスマートにこなすことができるようになるが、 しだいに成長の度合いは鈍るだろうし、 なにより部下が育たない。 ある段階まで来たら仕事は部下に譲って、 自分は違うことをすべきだろう。 そうすれば新しいチャレンジができるし、 自分を大きく成長させることもできる。
今日、本屋で他に読みたいと思う本がなかったので仕方なく手に取った本:
千円札は拾うな。
安田 佳生 (著)
をパラパラと見たら、 まさに私が考えていたようなことが書いてある。 引き込まれて思わず一気に読んでしまった (私がいきなり本に没頭し始めたので、一緒にいた妻が不機嫌になってしまったが)。
久々に、いい本に出会えた感じがした。 さっそく私の参考文献リストに追加した。 それにしても、この本のタイトルはいただけない。 以前からこの本が平積みになっていたのは知っていたのだが、 タイトルからは食指が動かなかった。 そもそも、「お金を拾うな」というのは当たり前ではないか、 と思ったからだ。たとえ一万円札だろうと、 何か高価そうな品物だろうと、私は拾わない。
私の参考文献リストに加えていて気付いたのだが、 安田氏の著作はすでにリストにあった:
採用の超プロが教えるできる人できない人
安田 佳生 (著)
この本もオススメである。私の面接のやり方は、 この本に影響を受けた面がたぶんにある。
2006年05月12日資産とは、お金を入ってくる源泉。 お金が出ていくほうは負債。 持ち家を資産と思っている人も多いが、 持ち家に自分で住んでしまえば、 修繕費などでお金が出ていくことはあっても、 お金が入ってくることはない。だから負債。
金持ち父さん貧乏父さん
ロバート キヨサキ (著), 白根 美保子 (翻訳)
で述べられているように、 お金のしくみはいたって単純である。 少なくとも普段、技術者たちが相手にしている高度な技術に比べたら、 遥かに遥かに単純である。 負債を減らして資産を増やせば、 入ってくるお金が増える。 ただ、それだけ。
こんなに単純な理屈なのに、 多くの人は、 資産を増やすためにお金を使うより、 むしろ負債を増やすことにお金を使ってしまう。 例えばローンを組んで持ち家を買ったりする。 どうみても世間一般の人より遥かに頭がいいように思われる技術者たちが、 ことお金に関しては全くといっていいほど 頭を使おうとしないのはなぜなのか。
しかも、技術者の多くは、 他の人達が望むべくもない資産を持っている。
それは「スキル」。
しかも、わずかな投資(努力)で大幅に増やすことができる特異な資産である。 なぜ、この資産をもっと効果的に増やそうとしないのか。 なぜ、目先のキャッシュフロー (安月給) に目を奪われて、 自身の資産形成をおろそかにするのか。
2006年05月11日私が面接でよく聞く質問に:
生活するために働かねばならない、ということが仮になかったとしたら、
仮に、一週間何をしてもいい、と言われたら、何をしますか？
# 仙石浩明CTO の日記: 面接 FAQ (4) から引用
というのがあるのであるが、 意外なまでに多くの人がこの質問に答えることができない。
そんな馬鹿な、何をしたいか分からないなんて、 そんなことが有り得るのだろうかと思っていたのだが、 あまりにこの質問に答えられない人が多いので、 一つの仮説を立ててみた。
好きなことがない、あるいは明確にこれが好きと言えない人たちというのは、
「他の人に勝つ」ということに価値を見いだせない人たちなのではないか？
つまり、私の場合だと、 他の人にできないことが自分ならできる、 ということに自身の存在理由を求め、 この分野なら他の人に勝てる、という分野を追い求めてきた。
他の人に勝てれば、その分野が好きになるし、 好きになれば、それだけいっそうその分野に注力することになる。 そうすることによって実力がついて、 よりいっそう他の人たちより優位に立てた。 そういう正のフィードバックによって実力を磨いてきた。
だからこそ、私にとっては 好きなこと ＝ 他の人に勝てる分野
なのである。
この感覚が、 私にとってはあまりに自然な発想だったので気付かなかったのであるが、 もしかすると私が自明なものとして疑うことがなかった 「他の人に勝つ」という大前提が、 人によっては、それほど重要なことではないのかもしれない。 いや、むしろ他の人と同じであることに価値を見いだす人たちなのかもしれない。
2006年05月10日拙作 時刻表ビューア を、 Fossil/ABACUSのPalmOSが搭載された腕時計 WristPDA(腕パーム) に 移植して頂いた。
私は、時刻表ビューアのバージョンアップは 2000年8月を最後に行っていない。 その後、Linux Zaurus SL-C700 を使うようになってからは、 Palm 自体を使わなくなってしまっていたので、 時刻表ビューアを見ることさえなくなってしまっていた。
作者自身が忘れていたソフトウェアを、 新しい機種に移植して利用していただけたというのは 大変嬉しいことであり、 オープンソース化しておいて 本当によかったと思う。
2006年05月09日
出版社のWebページへ寄稿する理由って何だろう？
出版社のWebサイトには、著名人が執筆したコラムが多数掲載されている。
出版社にとっては、 サイトを充実させることによって 来訪者が増えるというメリットがあるのは分かる。 雑誌と違って流通コストがかからないから、 紙面の制限もないわけで、 こうしたコラムは多ければ多いほど好ましいに違いない。
しかし、執筆する側のメリットがよく分からない。 誰でも低コストで自分が書いた文章をネットへ発信できるし、 内容さえマトモであれば、 それがどこにあろうとあまり関係ないように思われる。 まして著名人が書くコラムであれば、 どこに置いたとしても すぐ広まるし、 大勢の人に読んでもらえるだろう。
逆に、出版社のWebサイトに置いたとしても、 内容がなく、著者が無名の人であれば滅多に読まれないだろう。 そのサイトの登録会員にメール等で告知することによって 一時的に読者を増やすことができたとしても、 あくまで一時的であって、 内容が読むに値しなければすぐ忘れ去られるだろう。
つまりWebの場合は、重要なのは内容であって場所ではない。
一方、紙媒体には Webとは異なる読者層へ届けることができるというメリットがあるわけで、 紙媒体への寄稿には書く側にも十分な理由があると思う。 私自身、何年か前に雑誌の連載記事を書いたことがあるが、 原稿料はオマケと思えるくらいの大きなメリットがあったと思っている。
したがって、執筆する側にとっては、 Webと紙媒体は根本的に異なるものだと思う。 にもかかわらず、Webサイトへの寄稿の場合も、 雑誌等への寄稿と同様の扱いらしい。 つまり、文章量に応じた原稿料のみで、 ページビューに応じた支払いとかの制度は無い、 という説明を、某出版社の編集者のかたから受けた。
それならなぜ、Webサイトに寄稿する人がいるのだろう？
単に、私が書く駄文には価値がないから原稿料だけで我慢しろ、
ということ？ (^^;)
実は私が知らされてないだけで、
Webページならではの報酬体系がある？
まあ、それならそれでかまわない ;-( ので、
原稿料以外のメリットとして、
どんなものがあるのか教えていただけると幸いである。
2006年05月08日会社説明会といいつつ、 要は私といろんな話題についてお話しましょう、 というノリですので、 私の日記 (CTO日記もよろしく) を見て、 波長が合いそうだと思ったかた、 ぜひ登録をお願いします。
おかげさまで第一回(5/9)と第二回(5/15)は満席につき、 現在は三回目を募集中です。
KLab(株) CTO仙石 (KLabセキュリティ(株) CTO を兼務) と語る、
「技術者の成長にとって一番役に立つ会社」
「技術者が自ら伸びていくことができる会社」とは
理工系の学生の皆様に、弊社で、 CTO仙石と少人数でコミュニケーションをとって頂く、 1次選考を兼ねた会社説明会をご案内致します。 皆様のお申し込みお待ちしております。
日時 2006/5/30(火) 13:30〜15:00
場所 KLab(株) 本社会議室 (六本木ヒルズ森タワー 20Ｆ)
CTO日記のほうで書いている 「面接 FAQ 〜弊社の面接で(私に)よく聞かれること、面接官自身が語る面接攻略法〜」を読んでおけば、 面接事前対策もばっちり ;)。
2006年05月07日「同時に考えよう (3)」で 「相手の気持ちになって考える」とはどういうことなのかを考えたのであるが、 そもそもこのタイトル自体が、 読み手のことを何も考えていないタイトルだったと反省することしきりである。
「同時に考えよう (3)」というタイトルは、 無意識の思考についての一連の考察のうちの一つという意味合いで使った。 後から読み直したときに、 関連する日記を見つけやすいように、 という書き手としての私の都合である。
この「GCD日記」は、 考えをまとめるための メモとしての位置づけで あるので、 書き手の都合を考えてもいいのかもしれないが、 100% メモであるなら公開したりせずにメモ帳に書けばいいわけであるし、 実際、そういう (非公開) メモを書いている。
そして、 「仙石浩明CTO の日記」のほうは、 考えをある程度まとめた上で公開に重きを置いた日記であるのだから、 読み手の都合だけを考えてタイトルを決めねばなるまい。
読み手のことを考えたタイトルとはどういうタイトルだろうか？ 毎日ブログを読む人というと、 沢山のブログを斜め読みする、という人が大半であろう。 一つの日記を時間をかけて読んでもらえるとは限らないし、 まして何日分にもわたるシリーズ物を順番に熟読してもらえるのは、 よっぽどの愛読者だけだろう。
もちろん、そういう愛読者は大切であるし、 そうやって真剣に読んで頂けるのであれば大変ありがたいことであるが、 大多数の読者にそういう態度を期待するのは間違いであろう。 そうなると、タイトルだけである程度内容が判断できることが好ましい。 そのトピックに興味のない人には読み飛ばしてもらう一方で、 愛読者になる可能性のある「見込み客」の目は、 たとえ斜め読みしていたとしても捕らえられるような キャッチーなタイトルでなければならない。
そういう適切なタイトルを考えることは、 本文を書くより難しく時間もかかりそうな気がするが、 まずはできるレベルから始めてみようと思う。
2006年05月06日stone 2.3a をリリースした。 stone 2.3 からの変更点は以下の通り。
二重 free するバグの修正
stone 2.3 における最も重大なバグ。 同時に大量に socket を close する、という利用パターンにて、 二つのスレッドが同時に同じ ExBuf に対して ungetExBuf を行なってしまうために、 二重 free が起きてしまう。 stone.c 2.2.1.11 で修正 (わずか一行の修正だが極めて重要)。
Pair を thread で処理しているときは scanClose 対象から外す。
thread 処理中は、そもそも close 要求が出ていないわけで、 当然 scanClose 対象から外れるはず、と思っていたが、 thread 処理中に proto_close をセットすることもあるわけで、 dowrite が ungetExBuf を呼ぶタイミングと、 scanClose が freePair を呼び出して ungetExBuf を呼ぶタイミングとが 重なる可能性があると思われるので、その防止策。
socket を close しないバグの修正
SSL_accept に失敗したとき、すなわち TCP レベルでの accept は成功したが、 続く SSL ハンドシェークで失敗した時に、 中継先の socket が open しっぱなしになるバグ。 これは、中継元 socket の accept に成功した時点で、 中継先の socket を open するが、 SSL_accept に失敗したときに close していなかったために起きた問題。 stone.c 2.2.1.8 で修正 (これもわずか一行の修正だが重要)。
SSL ハンドシェークを行なわない TCP レベルのヘルスチェックを stone の中継元ポートに対して行なったとき、 stone が open した socket がどんどん増え、 too many open files エラーが起きて accept 出来なくなったことにより発覚。
SSL_accept に失敗したとき、pair2 側に close 要求出すのを忘れていた。 SSL_accept に時間がかからない時 (localhost からの接続時) は、doaccept 内で freePair するので問題にならないが、 SSL_accept に時間がかかる時は、doReadWrite 内で p[i]->proto |= proto_close; するので、この時 p[1-i]->proto |= proto_close; も行なう必要がある。
epoll 対応 (select 版も大幅に性能向上)
select(2) の代わりに epoll(2) も利用できるようにした。 コンパイルオプション「-DUSE_EPOLL」をつけることにより epoll 版を make できる。 linux 2.6 以上のカーネルと、 glibc 2.3 以上が必要。
epoll 対応のため、stone のコード全体の見直しを行なった。 結果、(epoll を使わない) select 版も大幅にパフォーマンスが向上した。 「stone 2.3 が遅い理由」および 「stone 2.3a (候補) ベンチマーク」を参照。
アドレスキャッシュ機能の実装
Windows 2000 などで、gethostbyname が遅いという問題があるようなので、 proxy で resolv した IP アドレスをキャッシュする。 stone.c 2.2.2.11 で実装。
unix domain socket で uid 等の取得
SO_PEERCRED 参照。
<host>:<port>/http <sport> <request> [<xhost>...]
http リクエストにのせて中継します。<request> は、 HTTP 1.0 で規定されるリクエストです。 リクエスト文字列中、 「\」はエスケープ文字であり、 次のような置き換えが行なわれます。
\u 接続元のユーザID (番号)
\U 接続元のユーザ名
\g 接続元のグループID (番号)
\G 接続元のグループ名
stone.c 2.2.2.18 で実装。
ミリ秒単位のログ出力
stone.c 2.2.2.12 および stone.c 2.2.2.17 で実装。
health HELO コマンドの分割
stone.c 2.2.2.13 で実装。
2006年05月05日技術者にとっても、無知の知が重要、という話は以前にも書いた。 自分が何が分かっていないか正確に把握していれば、 適宜質問したり、勉強したりできる。 自身の実力がどのくらいか正確に把握できていれば、 判断を誤まらずに済む。
過去の成功体験がアダとなって失敗した、という話をよく聞く。 過去とは状況が変わっているのに、 今でも自分が正しい判断をできると思い込み、 過去の手法を現在に適用してしまう。 過去の成功体験を過剰適用してしまっている。
自信を持つことは悪いことではないが、 ともすると自信過剰に陥る。 自分の実力をどこまで正確に評価できるかが鍵だろう。 努めて自分の短所を見るようにしなければならない。
自分の短所は見つけにくい。 ついつい長所ばかりを見てしまう。 一方、他人の短所はよく見えるもの。 ならば逆に、無理矢理にでも他人の長所を見つけよう。 そうすれば、自分が何ができていないか見えてくるだろう。
2006年05月04日アナロジーで考えると理解しやすいのはなぜだろう？
新しい事柄を、すでに理解している事柄に対応付けると、 分かったような気になりやすいので注意が必要であるが、 どこまで類似していて、 どこが違うかはっきり意識しながら考えるのであれば、 アナロジーは素早くモノゴトの本質を見極める方法として有効である。
すでに完全に理解している事柄というのは、 頭の中にその事柄に対応する「回路」が出来上がっていて、 無意識の思考で高速に考えることができる。 一方、初めて見聞きする新しい事柄は、 当然のことながら頭の中にはなにも準備ができていないから、 無意識の思考で考えるのは難しく、 意識した思考で考えることになる。つまり非常に遅い。
ここで、もし新しい事柄の一部でも、 無意識の思考で考えることができるのなら、 つまりすでに理解している事柄と似ている点があるのなら、 その部分は無意識の思考に任せることができて、 理解を加速することができるのではないか。 おそらく、これがアナロジーで考えるということなのだろうと思う。
このように考えていると、 マービン・ミンスキーのフレーム理論が思い起こされる。 つまり知識の枠組みができている事柄についての理解が速い、 ということと似ているが、 単なる知識の整理にとどまらず、 無意識の「自動化された」思考によって、 新しい事柄への理解が加速されるのではないか。
その一方で、過剰な類推をしてしまう、 つまり無意識への「丸投げ」をしてしまうのが、 「分かったつもり」であって、 頭の中の回路がどこまで正しいのか、 つまり「どこまで類似していて、どこが違うか」を検証する必要がある、 ということなのだろう。
その検証を、意識して行ってもよいのだが、 検証を無意識の思考で行うことができれば、 さらに強力だろう。 これは、比喩のやりすぎや、論理の誤謬を「直感で」感じられる人は、 検証を実際に無意識の思考で行っているのだろうと思う。
2006年05月03日先月 4/14 19:30 NHK で、特報首都圏「就職戦線異状あり・格差社会の不安」と 題する番組があった。 新卒の学生さん達が「勝ち組になる」ことを目指して 就職活動を行なっているのだという。
そりゃ、勝てるものなら勝ちたいと思うのは人の常なので、 これから社会に出ていこうとする学生さん達が、 将来勝ち組になれるような就職先を選ぼうとするのは至極当然のことだと思う。
ところが
学生さん達曰く、「勝ち組になるため、儲かっている会社に就職したい」。
オイ、それは根本的に間違ってるぞ、と言いたくなる。 儲かっている会社、それはお金を産み出す仕掛けが確立している会社である。 つまりできるだけ属人性を排した、回り続ける仕掛けが確立している会社である。 このような会社が新卒採用を行なうのは、 仕掛けを維持するために「歯車」の補充を行なうためである。
すでに出来上がっている仕掛けは、それが陳腐化するまでは、動き続けるだろう。 動き続けるには若い人を採用し育てることが必須だから、 そういうことまでも含んだ仕掛けである。 このような仕掛けに参加すれば、 仕掛けの中で活躍できるレベルまで育ててもらえるし、 仕掛けが動き続ける限りは安泰である。
しかしそれは「勝ち組」ではない。 勝ち組なのは、放っておいても回り続けるその仕掛けを作り上げた人であって、 いったん仕掛けが回りはじめたとき、 その人はその仕掛けの中にはいないはずである。 それが「属人性を排する」という意味である。 「属人性を排する」すなわち「置き換え可能」な人材で 仕掛けを回すことであり、 置き換え可能な人材は「勝ち組」では有り得ない。
したがって、勝ち組になるには、 出来上がって回りはじめた仕掛けに歯車として参加するのではなく、 そういう仕掛けが無いところに参加し、 仕掛けを作る側にまわらなければならない。
もちろんどうやって仕掛けを作るべきか最初は分からないだろう。 当然、失敗することもある。 しかしそうやって無から有を作り出す経験を積んだ人材は決して、 置き換え可能ではない。 仕掛けを作り上げようと悪戦苦闘する組織は、属人性のカタマリである。 将来の勝ち組になるには、 そういった組織の中に身を置かねばならない。
続きを読む 2006年05月02日
人は働かねばならない、と誰が決めたんだろう?
働かなくても生活できるなら、働く必要はないわけで、
ただ単に、勤労は国民の義務だ、なんて言っても意味がない。
[技術]Agdaの紹介Flashから引用:
定理証明ツールが動いているところ、生まれて初めて見た。感動。自分もつかってみたいが、ドカタSEなのでそれよりやらないといけないことがあるのが悲しいところ。資産が50億ぐらいあったらニートになって毎日こんなことばっかりしたいな。これ、俺の夢（←駄目人間）。
50億もなくても生活できると思うが、 まったくお金を稼がずに生活しようと思うと、 数億は必要だと思われるので、 なかなか簡単ではない。
しかしながら、 技術者の生産性には人によって 3桁の差があるわけで、 並みの技術者の数倍の生産性がある人なら 大勢いるだろう。 そういう人たちにたとえば一日3〜4時間だけ 会社の利益に直結することをしてもらって、 一日の大半の時間は好きなことをやってもらう。 もともと生産性が高い人なら、3〜4時間の労働だけでも、 生活に困らないくらいの給料を出すことができる。
ほとんどの時間、 引きこもって好きなことをしているように見えるわけで、 まあニートみたいに見えるかもしれないが、 向いてない仕事を嫌々やるより、 好きなことをとことん突き詰めるほうが、 よほど健全だと思うし、 実は社会への貢献度合いも高くなる可能性が高い と思うのだが、どうだろうか。
2006年05月01日epoll版 stone で EPOLL_CTL_ADD を行うタイミングについて。
基本的には doAcceptConnect 内で行う。 つまり、中継元からの接続を accept し、 中継先へ connect するルーチン。 このルーチンは、Pair リストへの挿入 (insertPairs) を行う 唯一のルーチンでもある。 このルーチンで EPOLL_CTL_ADD を行わないのは、以下の場合のみ。
- (1) proto_close フラグが立っている場合
- エラー等の原因で close 要求が行われている場合、 中継の必要がないから、EPOLL_CTL_ADD も行わない。
- (2) 中継先の Pair かつ proto_noconnect フラグが立っている場合
- proto_noconnect フラグが立っているのは
中継を行わない Pair であることを示す。
この場合は、EPOLL_CTL_ADD を行う必要はない。
ところが、stone を proxy として用いるとき、 proto_noconnect フラグが立つ。 これは中継元からリクエストヘッダを受け取るまでは 中継先が決まらないため。 このとき、(2) に該当するので EPOLL_CTL_ADD が行われない。
このため、stone.c 2.2.2.20 では、proxy として用いたとき EPOLL_CTL_ADD が行われず、 中継先への connect 完了を検知できなくなってしまっていた。
中継先が決まった段階で EPOLL_CTL_ADD を行うよう修正。
$Id: stone.c,v 2.2.2.21 2006/04/29 07:32:28 hiroaki_sengoku Exp $
