2006年 9月 (2)。

だ と す れ   ばー

Last Modified: Tue Sep 19 07:37:41 EDT 2006 (09/19, 20:37 JST)

Sep 19 [Tue]


(06:50)
あーーー。ねむい。 今回もまた、なーんか忘れがあるような気のする。 それにしても、なぜ毎回毎回もうちょっとゆっくりできんものかと思ってしまう。
(07:37)
ほんとに。

Sep 18 [Mon]


(08:49)
年月日を扱うときの y, m, d という変数を「山田」と読んでしまうのはオレだけだろうか。
(10:35)
おいコラ、なぜコイツは 192.168.194.1 などとゆーアドレスからログインしてるんだ?
(13:48)
げーそ。Corpus オブジェクト (おジュゲブゴ) を singleton にしようとしたら pickle できんじゃないか!! Pickle は便利だけど、いろいろな意味論を破壊するなあ。 こういうときには、架空のクラスをつくっておいて pickle しておき、 unpickle 時に実際のクラスにくっつけて委譲させんのかな? Proxy ってヤツか? もうどうでもいいよ、くそったれ。
(18:20)
ったく…オレは…お人よしすぎるんだよ…。

ぶつぶつ…

(22:42)
きょうは Chen のためにだいぶ時間をつぶされた。なんか、ムカつく。 これが H嬢や Javier に時間をつぶされてもあまりムカつかない。 なぜだろう? ようするに彼は「ワガママなくせにあまり仕事をしない」のである。 セキネさんに「こんだけ環境を整えてやってんだから、 奴にちゃんと仕事させなきゃだめですよ」とクギをさしておいたが、 どうなることやらね。

それにしてもネットワークの授業はホントに楽しそうだなあー。 とくに、課題プロジェクトが。学生は教授と相談して 学期末までに (授業と並列で) グループでプロジェクトを終えるのだが、 このテーマがとっても楽しそうだ。マンハッタンのビルの谷間で ワイヤレスネットワークがどうふるまうかを調べるとか、 ニューヨーク市内すべての病院の医療情報を集約したデータベースで 個人情報を漏らさずに検索できるようにするとか (当然、暗号を使う。 実際のデータベース構築プロジェクトと協力できるらしい)、さらには 「中華ファイヤーウォール (Great Firewall) のアーキテクチャを調査する」というのまである。 なんか Jinyuan のねーちゃんによれば、希望者は実際に中国国内にあるマシンが 使えるようなことをいっていた。ホントかっ。ほかにも、この授業は システム班のよき伝統というべきか、毎週 TA による補修がある。 おまけにシステム屋の博士学生が 3人いて、こいつらがそれぞれ自分の 研究テーマに近いプロジェクトの面倒をみることになってるので、 やろうと思えばかなり専門的なことまでできるようになってる。 学生ひとりあたりに対する手のかけかたが半端じゃない。こういう、プロジェクトぐるみ (日本の大学でいえば「研究室ぐるみ」) でいっこの授業に持てる資源すべてを 費やすというのは日本ではまっっったくといっていいほどお目にかかったことがない。 これだもんなあ。差がついて当然ですよね。

(01:10)
あってほしいときになく、なくてもいいときにある、それが時間だ。

そんな時間だ。

盆水覆に返らず。

Sep 17 [Sun]


(17:56)
さいきん、「○○○○○○」という表現を使いすぎてるようの気のする。○○○○○○。

もちろん、世の中に金で買えないモノなどあるわけがないでしょうよ。 Sure enough.

(18:36)
単なるデータ構造の偶然を利用したコードはよくない。わかりにくいし、拡張性もなくなる。 わかっちゃいるんだけど。柳の下のどぜう。
(21:49)
え へ  ら

     え   へ ら

"When" を日本語で「ホエン」と書くのはやめてください。 これを見るたびにいつもホエホエした気分になってしまいます。 とっこべとら子。

(00:46)
そういえば、システム班の部屋の前に貼ってあるマンガ。 これにはウケた。そもそも最初から誤解があるのがおかしいが、 なによりウケたのは 2コマ目と 3コマ目で "How the project manager understood it" のあとにエンジニアが無理矢理な設計をしたところである。 この強引さを見よ!

Sep 16 [Sat]


(13:10)
さいきん、ほんと spam が多いよなあ。 とりわけ週末にかけて多くなるようだ (気のせいかも)。 あいかわらず新山の手製フィルタはかなりうまく動いているのだが、 いま使っている新しいメーラには「メールを削除する機能」がないのである。 ただ、表示しないよう隠すだけ。 なぜなら削除できるようにするとデータ構造の設計がめんどくさいから。 圧縮してるから容量の増加はそんなでもないのだが、 これが今後何年も続くとなるとバカにならない。くそったれ。どうしてくれよう。

ちなみに、いまたまっているメールは 73000通で (圧縮した状態で) 約250MBytes だから、 200GB のディスクだと 5000万通ぐらいまでは OK ってことになる。 しかしオレはいったい死ぬまでにあと何通のメールを受けとることになるんだ? 1日 100通ぐらい受けとるとして、あと 50年生きるとすると 50×365×100 = 182万5000通。 これが 1日 5000通 (ホリエモン級) になったら 9125万通。 あ、こりゃダメだな。こうなったら死ぬまでにもういっかいハードディスクを買い換えるか、 メーラを作り直さないと。しかしそもそも 1日に読んだり書いたりできるメールって、 新山の場合はせいいっぱいがんばっても、たかだか 20〜30通ぐらいだと思う (アホな 1行メールだけならもうちょっといけるかもしれないが)。

1通のメールに (ヘッダを除いて) 平均して 3KBytes のテキストがあるとして、 せいぜい 100KBytes/日ぐらいが人間のテキスト処理の限界か。 だけど実際にはこんなに無理だと思う。本を書いていたときは、 調子のいい日でも 1日に 10KBytes (つまり 1日約 5000字) 書くのがせいぜいだった。 まあメールと書籍じゃ文が違うけど。プログラミングだともうすこしカサが増えるので 1日 20KBytes ぐらいかもしれない。それでも 1日に 1000行以上書くのはむりだ。 つまり、100年間のあいだ毎日これを続けたとしても、オレが生涯に生産できる テキストの量はたかだか数百MBytes ってことになる。ちなみに新山が去年 1年間にタイプした シェルのコマンド量は、約 800KBytes なので (履歴の再利用が多いので、実際のタイプ数はもっと少ない)、 これを加えてもせいぜい数十MBytes しか増えない。人間、死ぬまでに 1GBytes のテキストを 書くのはちょっと無理なんではないかと思われる。

さて、読むほうはどうなんだろう? 1日 100通ぐらいのメールなら読めるかもしれない。 それでもせいぜい死ぬまでに数GBytes というところだろうなあ。 そうすると、世界の人口が 100年間に処理するテキスト量はいったいどれくらいだろう? 人口を 100億人としてテキトーに計算すると、 100億×100年×100MBytes = 109+6+2+2+2 ≒ 1000EBytes か?? こりゃちょっと多すぎだ (というか最初の見積りが多すぎた)。 実際には、これまでの人間の音声会話をすべてテキスト化しても せいぜい数百 EBytes にしかならない、というのがどっかに書いてあった (まあ、hotwired かどっかだったよーな気がするからぜんぜんアテになんないけど)。 まあ、どうでもよろ。

実際、量の問題ははっきりいってどうでもいい。 問題なのはむしろシステムの「複雑さ」の増加だが、これは単純に算数で計算できないからこわい。 たぶん昔も今も、人間社会が許容できる根本的な複雑度というものは変わっていなくて、 最近はそれの上限にヒットして破局するようなケースがますます増えているような気のする (人間はそんなに速く頭よくなれないし、そもそもうちらはすでにチューリング完全になっている。 これ以上何を望むのか?)。こりゃあ、アレだよ。将来なにやらヘンテコな揺り戻しが起きるか、 あるいはこのままカオス化して破滅 (これは、ゆっくり起こるかもしれない) かのどっちかだね。

spam に話を戻すと、たぶん spam がいまのペースで増加すれば、5年後ぐらいには S/N比が 0.01 ぐらいになって、電子メールは使いものにならなくなるんではないかと思う (すべての人が精度 99% の spam フィルタを使っていれば話はべつだけど)。 オラ知らね。まあ、そのころまでに「いざとなればネットなんかなくても何とかなるよ」と言えるように なってればいいけどね、オレの生活が。電気やガスはどうだろ? あやしいな。

妻子持ちじゃない新山のような人間の一番の欠点というのは、 このように「いつリセットされてもオッケーな人生」を送っていることだ。 つまり最終的には何が起ころうとも「どうでもよろ」と言えてしまうので、 このままでは何を言おうが、人生をなめてるガキの世迷い言にしかならない。 まあ、それはそれでいいんだけど。どうでもよろ。

(14:54)
またもや
ティッヒュ
洗濯!!

正正正正正T

(00:29)
夕方、大学にいったらH嬢がいたので、また 1時間以上話しこんでしまった。 ようするにグチを言っていたのだけど。そういえば給料の話になったのだが、 米国の平均的な大企業では、PhD の学生インターンの給料はだいたい月 6000ドルぐらいである。 これだけでも相当ビックリする額なのだが (日本にいるオレと同年代の 大手メーカー勤務の人々もこんなにもらっているのか?)、IBM なぞはもっと高く、 新山のいた某社はさらに高かった。Chen に聞いたところ、 競合する某社なぞもだいたい同じくらいの額だという。 MS もまあ似たよなもんだろう。インターンの分際でこれだから、 正社員はとーぜんもっともらっているわけだ。 だからこの 3ヵ月間で新山の預金残高は瞬間的にドカンと上昇した。 親にこのことを話したら「お前、日本に帰ってくるな」といわれた。 日本の会社じゃこんな額は絶対に稼げないんだからと。たぶんそうだろうな。 でもオレはあんな方法で何も知らない人々から巻き上げられたカネを平気で 使うことはできんよ (まあどんな方法かは守秘義務契約違反で訴えられるから書けないケドね…)。 いくらオレがどうしようもない人間だとはいっても、そこまで落ちぶれちゃあいない。 結局 (ケッキョキ、) 新山はこのアブク銭を全部寄付しちゃったんだけど (知らなくて驚くかもしれませんが、 新山は正真正銘のバカです)、はっきりいって哀しかった。 ここで善人ぶるつもりはない。 これだけのカネを自由に使えりゃ両親をファーストクラスで欧州に行かせて、 豪華 2週間の旅ぐらいはさせてやれただろう。 たぶんこれほどの金額を寄付することは生涯で二度とないと思う。 あまりに金額が大きいので、(支払いに使った) Paypal からわざわざ確認の電話がかかってきたのには笑えた。 でも、これは最初から計画していたことではあったが、仕事には手を抜いてないと思う。 ちなみに、この会社はインターンでも競争率がとても高い (らしい) のだが、コネなぞは一切使ってない (だって実力で受けなきゃ面白くないじゃん)。 会社ではいい子にしていたし、稼いだ金をどう使おうがオレの勝手だよね。 今ではすっかり預金も元にもどって (実際にはこの間は 貯金を食いつぶしていたので、生活費ぶんだけ減っている)、サッパリした身になりました。

ついでにいうと、この会社では面接のときでさえ NDA にサインさせられた。 質問事項を外部に漏らすなってさ。キチガイ。ほかにも、部外者が社内に入るときは 毎回 NDA にサインさせられる。そんで社員になると昼食はタダで、 毎週アルコールが出て、ときどきみんなで遊園地に行くと。 いやあ、じつに賢いよね。この会社はオープンソースがなくなったら何もできないほど オープンソースに依存してるんだけど、 たとえ GPL2 でライセンスされていてもバイナリさえ外に出さなければ… いや〜〜かしこいなあ〜〜!!! 感心するよ。 まったく、こんな会社で働いてる人々には絶対、勝てませんわ。 オレも連中と同じくらい賢くなれればいいんだけど。 てゆうか、履歴書にも書きたくないよね、こんなの。 バカをだますにはもってこいの社名なんですが…。

ああいうとこにいると人間、ぜったい卑屈になると思う。 サッサと学位とって日本に帰ろう。やっぱオレは貧乏でも世間様に顔向けできる職業がいいからな。 (といっても、連中はホントに自分たちが善人だと信じてるのかもしんない、こわいこわい。)

(01:20)
そういえば某 GALE プロジェクトの評価結果がほぼ出たらしいが…。 なんでも、20種類以上もの異なるやり方でスコアが算出されたらしい。 と、いうのは、こうしておけばすべての参加チームがどこかしらの部門で「成績がよかった」ことになり、 また来年もみんなで予算ゲットできるからだって。そんなアホな! と思ってはいけない。これが世の中というもんである (オレがいっても全然説得力ないな)。 とりあえず、うちの大学は切られないことは確実なので、ひと安心ってところだろう。 まあオレとしても直接関係ないとはいえ、Ralph が予算獲得のためにまたヒーヒーいうのは見たくない。 しかし来年度の犠牲者は H嬢よりもさらにツラいんじゃないかなあ…。 そしてそれはそれは S嬢になる可能性が大大なのだが。 ああ、またオレはこんな残酷なことを。

そういえば、さかポンは大大 (大盛りのさらに上、でも金額は同じだった) をやめちゃったって聞いたけど、 いつの話?

(02:59)
食いすぎた。これじゃまた明日ネボウしちゃうじゃない蚊。 今日はちょっと暑い。

Sep 15 [Fri]


(07:58)
ガーーソ!! 雨ふってんのにきのう傘を大学に忘れてきた!! ばかばかばか。

…という夢を見た。そしたらあった。

(16:14)
一日じゅう忙しくて日記を書く暇がなかった。きょうの朝は、 Ido Dagan のところから言い換えと entailment をやっている学生がきてトーク。 なんかオレは関心のあるフリをしなければいけないらしい非常に関心があるので、 聞く。いや、別にいいんだけど、別に…。そのあとは彼らと昼飯を食いに行って (また Apple だった)、 帰ってきて、そのあとセキネ端末の設定をする。(臨時で来ている) Javier に 5年前の古くなった 端末をあげたら、Eclipse がろくにウゴカンというので (彼は Kubuntu を使っていたが、700MBytes のメインメモリ中の 600MBytes 以上がデスクトップ環境だけで食われていた、そりゃうごかんわな、キチガイ的)、 セキネさんの使っていた (= つまり、もとムラカミさんの使っていた) 2G のマシンと交換し、 かわりにセキネさんに端末として古いマシンをあてがう。5年の歳月をへて、このマシンがふたたび 彼のところに戻ってきたわけだ。そのあといろいろネットワークの設定をさせられ、 そのあと例の学生と研究のことで話し、「あいわらず評価が大変だよねえ」と文句をいって、 そのあとコサカさんに CMUCL で utf-8 を使うにはどうするかと聞かれ、うだうだ…。 結論からいうと、CMUCL では utf-8 を簡単に使えないらしい。 そんじゃあ SBCL にすっか、ということになる。そういえば SBCL って 結構よさそうなのに、今まであんまり選択肢に現れてこなかったな。 なんでだろ? どういうわけか知らないが、新山の中では CMUCL のほうがずっと有名である。 しかし有名であればいいというわけでもない (つうか、普通は有名なもののほうが悪い)。 とくに CMUCL は PPC で走らないから、オレは Mac の上では OpenMCL を使っていた。 ってゆうか Lisp って実装がありすぎるのが嫌いなんだよ! ま、Scheme はもっとそうだが。どでもよ (ろ)。ddnz
(17:03)
なんだ、こっちのほうがずっといいじゃん。 ところで (てくるde)、SBCL の SB ってのは S はカーネギーを、B はメロンを表してるんだってね。
(18:33)
ぬんじゃあああ!! 激ドシャ降。 S嬢と Javier とコーヒーを買いにスターバックスに行く。 ところが、2人ともカサを持ってない。しかし新山のこのイナバ物置なみにでかい NYU傘があれば、3人入っても大丈夫だった (ホントに)。 そういえば、最近へれんに会ってないなあ。今週でインターンは終わりのはずだが、 トンとオソタサ (= 音沙汰) なし。ちゃんと生きてんのか?? やつぁ。
(22:00)
ジェネレータ関連で、ものすごーーーく見つけにくかったバグ:

まず、このような関数を定義する。

def foo():
  for i in range(10):
    yield i
    bar()
  print 'finished'
  return
これを実行すると、次のような結果を期待するよね。 つまり foo() を最後まで実行すれば、 print文は必ず実行されるといっていい:
>>> print list(foo())
finished
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

ところが、ある場合にはこれがこうなるのだ!!

>>> print list(foo())
[0]
なぜか? それは関数 bar()StopIteration を出していたからである。
def bar():
  a = iter([])
  a.next()      # raises StopIteration
  return

これは本来 foo() で止まるべきはずが、foo() の外にある list() まで波及してしまったので、結果として list は 途中で終了し、 foo は最後まで実行されないまま終わってしまった。 しかもやっかいなことに、 この StopIteration 自体は list() が 吸収してしまうので、実際のエラーには出てこない。

この問題は、a.next()try: 〜 except: で 囲ってやれば解決する。

def bar():
  a = iter([])
  try:
    a.next()      # raises StopIteration
  except StopIteration
    pass
  return

しかしこれは大変に危険だ。 ほんらい、list からみれば孫の呼び出しにあたる関数 (bar) が、 親である foo をとびこえて list を正当にコントロールしてしまっていることになる。 next() を使うときゃ気をつけましょう…。

Sep 14 [Thu]


(12:01)
またもとに戻った…。
(16:58)
午後になったら晴れてきた。

疑問その 1: 世の中はほんとにせち辛いのか。 「以前にも増して」ということはないと思う。もしそう見えるとしたら、 それは一部のアホがせち辛く見せているだけではないのか。

断定その 2: 世の中はせち辛い。 なぜならそうだから。照明終わり。以上。

プラスチックっぽい顔をした人がこっちを見ていた。怖かった。そるあ怖いわな。

音声の意味論とキーボードの意味論について。 ほとんどの場合 (ホドント)、この 2つは別物だが、 それでも夕暮れ時に口笛を吹いてはいけない。なぜなら。

(18:38)
google://d41d8cd98f00b204e9800998ecf8427e/ (189,000)

google://da39a3ee5e6b4b0d3255bfef95601890afd80709/ (136,000)

おまけ: google://68b329da9893e34099c7d8ad5cb9c940/ (785)

(22:00)
かんげきーーーーーーーーーーーーー!!

いや、なんでも言ってみるもんだ。本当に。 今日はコーフンして寝つけないかもしれない。 こう考えると、オレって案外、 ゲリラ的な人生を送っているのかもなあ。 よく知らんけど。

Sep 13 [Wed]


(12:33)
新しいメーラにデータを移行するときにはいつもキンチョーーする。 それが自作のメーラだと特に。 バックエンドの形式をごっそり変えたので、結構やばい。 「うぎゃあああ! メッセージが消えたああ!」とかいうことはショッチュウ頻繁に起こりうる (ウソ、実際にはまだ起こっていません)。こわいこわい。 自分としては堅牢に設計したつもりだが、 という 3つの要求を満たすのはなかなかむずかしい。
(14:02)
がああーーーーん! 今日の SRG のトークに出るの忘れた!! それにしても、最近は言語処理よりもシステム系のほうの話にばかり出ているような気のする。

システム的な研究分野でひとついいと思うのは、 この分野には研究の「趨勢」とでもいうものがあることだ。 システム屋というのはつねに一定のプレッシャーにさらされている。 つまり技術はいつも (ほとんどその方向は予想できないが) 発展しているし、 計算機システムの責任もここ数十年のあいだずっと重要でありつづけているので、 システム屋はそのときどきで出てきた問題を無視するわけにはいかない。 全体として、システム系の研究者というのは昔からほぼ同じ方向を向いて (というか向かされて) いる。 だからある研究論文を読むときも、その研究を システム史全体の流れの中でとらえることができて、 「この研究はこういう流れの中にあって、過去からのこういう成果をふまえつつ こっち方面の解決策をさぐっている」というように位置づけることができる。 だからシステム研究にはいわゆる「前線」があって、それは多少はバラつきつつも、 時間とともに確実に広がっているわけね。

ところが、これに比べると自然言語処理の研究というのは「群衆」である。 流行はあるが、それはべつに研究の地平を広げるわけでもなく、ある限られた領域の中で 研究者の群れが「今度はこっちが流行ったぞー! どどどどど」と行ったりきたりしているという構図。 なんしろ世間の状況とかほとんど考えなくていいので、何が起こってるかっつうと

ということになる。 構文解析とか POS なんてもう 10年以上も前にできてるのに、いまだに 「新しいアルゴリズムで精度が 0.2パーセント向上…」とかいってるのが毎年のようにいるし。 みんな最初からてんでバラバラな方向で、しかも同じところを行ったりきたりしているので、 ところどころに一発屋が出ては消えていく、というのの繰り返しだ。 これで何かが「発展している」と考えられる人というのは平和なこってすよ。 これはこの分野があまりにも多様すぎるからこうなるんだろうか。 機械翻訳などに限ればそれなりに「方向」のようなものはありそうな気がするけどね (しかし機械翻訳はこの分野自体がすでに終わってるので…以下略)。 とりあえず情報検索はいまだに 70年代あたりで足踏み中。 その他のアプリケーションは、現在のところ人気がないため予算がつかない。 ああ、真の原因はこれか。??
(18:05)
やばい。雨ふりそふ。
(21:03)
ふらなかった。が、買い物しないまま帰ってきてしまった。 今晩のおかずどうしよ。 あっ、冷蔵庫にまだ冷凍ギャウザ (made in China[town]) があるっ。 そういえばチャイナタウンは最近あまり行ってなかったな。 涼しくなったからこれからはどこでも歩きまわれる。

そういえば、むかし「将来の夢は妊娠すること」と書いていた知り合い () がいたが、 新山の将来の夢は冬眠だ。 しかし冬眠といっても、SF であるような保護器に入るやつじゃないぞ。 クマとかがやっているような、冬の前にたらふく喰っておいて、 冬の最中はひたすら寝ているだけ、というのがやりたいのだ。 言うまでもなく、これは無理である。妊娠のほうがまだ簡単かもしれない。 そういやムーミンの世界ではかれらは冬眠する種族だったが、 なぜかスクルッタおじさんも冬眠していたなあ、彼は人間のはずなのに…。 100歳ぐらいまで生きれば、身体が仙人化して冬眠が可能になるのだろうか? いやはや、この先の人生が楽しみである。

(01:28)
こえっこ。

まあ、ダメもとだ。

しかし、こういうときに長いモノにまかれている人って楽だよなあ、と思う。 自分じゃ大したことしてなくても、なんか関係してる 有名な名前をだしゃスゴいと思ってもらえるワケだから。

もっとも、オレもやろうと思えばそうできたのかもしれない。 だが、たとえ原理的に可能でも、そんな人生オレには 堪・え・ら・れ・な・いんだよ。わかる??

なぜ堪えられないのだろう。なぞだ。

とりわけそういうのにご執心な人々を多く見てきたからかな。 わかんない。

Sep 12 [Tue]


(10:36)
うう、さぶさぶ。今日は長袖きてくんだった。

SSH のパスワード推測攻撃を分析する。 http://www.securityfocus.com/infocus/1876。 彼らは専用のプログラムを使って、ユーザ名のほかに、 よく試されるパスワードも分析している。それによると 「123456」とかがよく試されてるらしいが… あー、いくら UNIX が簡単だといっても、こんなパスワードを何も考えずにつける奴でも使えたっけ? UNIX って。そもそもコマンドとか覚えなきゃいけないんだよ。ls とか yes とか。 できる???

(15:17)

Python の email.Header の読み込みが異常に遅い。 どうやっても 0.1秒はかかる。内部の正規表現コンパイルにかかる時間らしいけど、 どうにかなんないの?

$ time python -E -c 'import email.Header'

real    0m0.105s
user    0m0.063s
sys     0m0.016s

ちなみに urllib2 はさらに遅く、0.2秒以上かかる。 さらにいえば、これは PYTHONPATH をまったく無視したときの結果で、 PYTHONPATH にあれこれ値を入れておくと起動時間はこの 3倍近くにふくれあがる。 こまったもんだ。

(16:51)
/dev/null == 事象の地平線。

じぞうって??

(00:37)
ううーー、今日は久々に LispNYC のミーチィングに出てきたが、さみかった。 それにしても FreeBSD の dudf は Linux とちがって デフォルトで 512bytes のブロック数を返すので、一瞬アセるなあ。

どうでもいいが Javier はすっかり日本食にハマったらしい。 でも、寿司って日常的に食う料理じゃないんだよ。

Sep 11 [Mon]


(14:46)

S嬢 (UNIXぜんぜん知らない) を PuTTY でうちのサーバにログインさせるまでの経緯:

  1. PuTTY、PuTTYgen、Pageant をダウンロードさせる
  2. 鍵を生成してメールで送らせる。
  3. うげっ、これ SSH1 の鍵じゃん!
  4. SSH2 の鍵を生成してメールで送らせる。
  5. ログインできない。
  6. "Account locked" になってた。 (adduser した直後だと passwd 欄に "*" が入っている)
  7. まだログインできない。
  8. Denyhosts にブロックされてた。(何度も失敗したため)
  9. やっとログインできる。

あ〜〜、疲れた〜〜。いつもいつも SSH で公開鍵を使わせるのにはホントに苦労する。 こういうことが続くと最終的にみんな「パスワード認証でいいじゃん」ということになっちまうんだよな。 これは何とかせにゃいかんだろうな。

(01:49)
きょうはちゃんと日記を書コウと思っていたノニ、 いつのまにかこんなネムネムの時間になってしまーた。

きょうは Network and Distributed Systems の授業に出る。夜7時から。 授業が終わって外に出たらサブかった。 内容はワイヤレスネットワークと P2P の動向を追うというもので、 プロジェクトを除けばおもに授業中にやることは論文を読んで議論することである。 いやー、やっぱり授業が始まると身がひきしまるね! オレって、生まれつき学生に向いてるんかもしれない。 論文を批判的に読むというやりかたは、日本にいたときにはほとんど習ったことがない。 ゼミや輪講ではいちおう論文を紹介するが、「批判的に読む」という視点は ほとんどなかった。しかしまともな研究者を育てるためにはこうした訓練は 必要不可欠だと思われる。こっちではそういう授業はすでに 2つほど取った (Honors OS と Security の授業は実装もするが、ほとんど文献中心だった)。

この授業は奇妙なことになぜか 2人の助教授が受け持っている。 ひとりはインド人のあんちゃんで、もうひとりは Jinyuan の姉ちゃんだ。 今日は最初ということで、なんやら「人間ネットワーク」のようなことをやって遊んだ(?)。 これはなかなか楽しい。まず、学生全員に紙が渡される。最初にそのうちの何人かがランダムに選ばれ、 選ばれた学生は紙切れをちぎって、自分の名前とランダムな 6桁の数字、 そして 8バイトまでのデータを書く (ここからどういう情報が読みとれる必要があるかは前もって教えられるが、 どういうふうに書くかというプロトコルの詳細は各自考えねばならない)。 これを 2部つくり、それぞれを 1部ずつ両隣の学生に渡す。このあと 5分間ぐらい、 学生は回覧してきたこれらの紙切れ (パケット) を前後左右の学生にランダムに 「ルーティング」するが、このとき各パケットの情報を自分の紙に書きだしておく (これがいわゆる「ルーティングテーブル」になる)。ある程度の時間がたった後、 教授がランダムに学生を指名し、特定のパケットに関する情報とその起点への最短パスを推測させる、 というもの。

それから、きょうは久しぶりに Chenと会った。またヤツのどうでもいい話に長時間つきあわされる。 彼はこの夏は西海岸にある某社でインターンをしていたらしい。そりゃあよかったですね。 ちなみにセキネさんとも (2ヵ月ぶりぐらいに) 会ったが、彼は彼で悪の帝国から 帰ってきたところなのだった (なんでも C# を使ってたらしい)。 そりゃあよかったですね。どうでもよろ。

どうでもいいが (ddmyr)、うちの学科で「Unix Tools」という授業を受けもっている Jeffery Korn というおっさんは (kシェルの) David Korn の息子なんだって。 親子そろって UNIX オタクかよ!


Document ID: 3bff1b4cc478f3415a0ec172fc204861

Yusuke Shinyama