だ と す れ ばー
pickle
できんじゃないか!! Pickle は便利だけど、いろいろな意味論を破壊するなあ。
こういうときには、架空のクラスをつくっておいて pickle しておき、
unpickle 時に実際のクラスにくっつけて委譲させんのかな?
Proxy ってヤツか? もうどうでもいいよ、くそったれ。
ぶつぶつ…
それにしてもネットワークの授業はホントに楽しそうだなあー。 とくに、課題プロジェクトが。学生は教授と相談して 学期末までに (授業と並列で) グループでプロジェクトを終えるのだが、 このテーマがとっても楽しそうだ。マンハッタンのビルの谷間で ワイヤレスネットワークがどうふるまうかを調べるとか、 ニューヨーク市内すべての病院の医療情報を集約したデータベースで 個人情報を漏らさずに検索できるようにするとか (当然、暗号を使う。 実際のデータベース構築プロジェクトと協力できるらしい)、さらには 「中華ファイヤーウォール (Great Firewall) のアーキテクチャを調査する」というのまである。 なんか Jinyuan のねーちゃんによれば、希望者は実際に中国国内にあるマシンが 使えるようなことをいっていた。ホントかっ。ほかにも、この授業は システム班のよき伝統というべきか、毎週 TA による補修がある。 おまけにシステム屋の博士学生が 3人いて、こいつらがそれぞれ自分の 研究テーマに近いプロジェクトの面倒をみることになってるので、 やろうと思えばかなり専門的なことまでできるようになってる。 学生ひとりあたりに対する手のかけかたが半端じゃない。こういう、プロジェクトぐるみ (日本の大学でいえば「研究室ぐるみ」) でいっこの授業に持てる資源すべてを 費やすというのは日本ではまっっったくといっていいほどお目にかかったことがない。 これだもんなあ。差がついて当然ですよね。
そんな時間だ。
盆水覆に返らず。
もちろん、世の中に金で買えないモノなどあるわけがないでしょうよ。 Sure enough.
え へ ら
"When" を日本語で「ホエン」と書くのはやめてください。 これを見るたびにいつもホエホエした気分になってしまいます。 とっこべとら子。
ちなみに、いまたまっているメールは 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 フィルタを使っていれば話はべつだけど)。 オラ知らね。まあ、そのころまでに「いざとなればネットなんかなくても何とかなるよ」と言えるように なってればいいけどね、オレの生活が。電気やガスはどうだろ? あやしいな。
妻子持ちじゃない新山のような人間の一番の欠点というのは、 このように「いつリセットされてもオッケーな人生」を送っていることだ。 つまり最終的には何が起ころうとも「どうでもよろ」と言えてしまうので、 このままでは何を言おうが、人生をなめてるガキの世迷い言にしかならない。 まあ、それはそれでいいんだけど。どうでもよろ。
正正正正正T
ついでにいうと、この会社では面接のときでさえ NDA にサインさせられた。 質問事項を外部に漏らすなってさ。キチガイ。ほかにも、部外者が社内に入るときは 毎回 NDA にサインさせられる。そんで社員になると昼食はタダで、 毎週アルコールが出て、ときどきみんなで遊園地に行くと。 いやあ、じつに賢いよね。この会社はオープンソースがなくなったら何もできないほど オープンソースに依存してるんだけど、 たとえ GPL2 でライセンスされていてもバイナリさえ外に出さなければ… いや〜〜かしこいなあ〜〜!!! 感心するよ。 まったく、こんな会社で働いてる人々には絶対、勝てませんわ。 オレも連中と同じくらい賢くなれればいいんだけど。 てゆうか、履歴書にも書きたくないよね、こんなの。 バカをだますにはもってこいの社名なんですが…。
ああいうとこにいると人間、ぜったい卑屈になると思う。 サッサと学位とって日本に帰ろう。やっぱオレは貧乏でも世間様に顔向けできる職業がいいからな。 (といっても、連中はホントに自分たちが善人だと信じてるのかもしんない、こわいこわい。)
そういえば、さかポンは大大 (大盛りのさらに上、でも金額は同じだった) をやめちゃったって聞いたけど、 いつの話?
…という夢を見た。そしたらあった。
まず、このような関数を定義する。
これを実行すると、次のような結果を期待するよね。
つまり
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()
を使うときゃ気をつけましょう…。
疑問その 1: 世の中はほんとにせち辛いのか。 「以前にも増して」ということはないと思う。もしそう見えるとしたら、 それは一部のアホがせち辛く見せているだけではないのか。
断定その 2: 世の中はせち辛い。 なぜならそうだから。照明終わり。以上。
プラスチックっぽい顔をした人がこっちを見ていた。怖かった。そるあ怖いわな。
音声の意味論とキーボードの意味論について。 ほとんどの場合 (ホドント)、この 2つは別物だが、 それでも夕暮れ時に口笛を吹いてはいけない。なぜなら。
google://da39a3ee5e6b4b0d3255bfef95601890afd80709/ (136,000)
おまけ: google://68b329da9893e34099c7d8ad5cb9c940/ (785)
いや、なんでも言ってみるもんだ。本当に。 今日はコーフンして寝つけないかもしれない。 こう考えると、オレって案外、 ゲリラ的な人生を送っているのかもなあ。 よく知らんけど。
システム的な研究分野でひとついいと思うのは、 この分野には研究の「趨勢」とでもいうものがあることだ。 システム屋というのはつねに一定のプレッシャーにさらされている。 つまり技術はいつも (ほとんどその方向は予想できないが) 発展しているし、 計算機システムの責任もここ数十年のあいだずっと重要でありつづけているので、 システム屋はそのときどきで出てきた問題を無視するわけにはいかない。 全体として、システム系の研究者というのは昔からほぼ同じ方向を向いて (というか向かされて) いる。 だからある研究論文を読むときも、その研究を システム史全体の流れの中でとらえることができて、 「この研究はこういう流れの中にあって、過去からのこういう成果をふまえつつ こっち方面の解決策をさぐっている」というように位置づけることができる。 だからシステム研究にはいわゆる「前線」があって、それは多少はバラつきつつも、 時間とともに確実に広がっているわけね。
ところが、これに比べると自然言語処理の研究というのは「群衆」である。 流行はあるが、それはべつに研究の地平を広げるわけでもなく、ある限られた領域の中で 研究者の群れが「今度はこっちが流行ったぞー! どどどどど」と行ったりきたりしているという構図。 なんしろ世間の状況とかほとんど考えなくていいので、何が起こってるかっつうと
そういえば、むかし「将来の夢は妊娠すること」と書いていた知り合い (男) がいたが、 新山の将来の夢は冬眠だ。 しかし冬眠といっても、SF であるような保護器に入るやつじゃないぞ。 クマとかがやっているような、冬の前にたらふく喰っておいて、 冬の最中はひたすら寝ているだけ、というのがやりたいのだ。 言うまでもなく、これは無理である。妊娠のほうがまだ簡単かもしれない。 そういやムーミンの世界ではかれらは冬眠する種族だったが、 なぜかスクルッタおじさんも冬眠していたなあ、彼は人間のはずなのに…。 100歳ぐらいまで生きれば、身体が仙人化して冬眠が可能になるのだろうか? いやはや、この先の人生が楽しみである。
まあ、ダメもとだ。
しかし、こういうときに長いモノにまかれている人って楽だよなあ、と思う。 自分じゃ大したことしてなくても、なんか関係してる 有名な名前をだしゃスゴいと思ってもらえるワケだから。
もっとも、オレもやろうと思えばそうできたのかもしれない。 だが、たとえ原理的に可能でも、そんな人生オレには 堪・え・ら・れ・な・いんだよ。わかる??
なぜ堪えられないのだろう。なぞだ。
とりわけそういうのにご執心な人々を多く見てきたからかな。 わかんない。
SSH のパスワード推測攻撃を分析する。
http://www.securityfocus.com/infocus/1876。
彼らは専用のプログラムを使って、ユーザ名のほかに、
よく試されるパスワードも分析している。それによると
「123456
」とかがよく試されてるらしいが…
あー、いくら UNIX が簡単だといっても、こんなパスワードを何も考えずにつける奴でも使えたっけ?
UNIX って。そもそもコマンドとか覚えなきゃいけないんだよ。ls
とか yes
とか。
できる???
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倍近くにふくれあがる。
こまったもんだ。
/dev/null
== 事象の地平線。
じぞうって??
du
や df
は Linux とちがって
デフォルトで 512bytes のブロック数を返すので、一瞬アセるなあ。
どうでもいいが Javier はすっかり日本食にハマったらしい。 でも、寿司って日常的に食う料理じゃないんだよ。
S嬢 (UNIXぜんぜん知らない) を PuTTY でうちのサーバにログインさせるまでの経緯:
adduser
した直後だと passwd 欄に "*
" が入っている)
あ〜〜、疲れた〜〜。いつもいつも SSH で公開鍵を使わせるのにはホントに苦労する。 こういうことが続くと最終的にみんな「パスワード認証でいいじゃん」ということになっちまうんだよな。 これは何とかせにゃいかんだろうな。
きょうは 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