改行するまでが遠足です。
保存するまでが編集です。C-x-
ところでみなさんウィキッペに寄付はしましたか? オレはした。雀の並だケド。 まあ、かなり暇つぶしさせてもらったからな。しかし今までに読んだ記事が ぜんぶ書籍になっていると仮定して、これくらいの額なら払うだろう、 という程度の金額なぬで、実をいうと全然 (ぞんぞん) すくない。 しかもコメントは「wikippe!」。まいったか。
これか?? これが crap なのか???
あれまあ。
で、今日は何がどうなるの?
隣の人がクシャミしてるのを聞いて、ふと指紋や声紋や笑紋と同じように クシャミにも「くしゃみ紋」があるのだということに気づく。
さて、私は
結局のところ、ユウベン国は 7:30 からやっていたので、 さっさと大学に来てしまった。久しぶりに朝早くにデリへ行って 気づいたことがある。冬になるとよくスープを買うのだが、 まだ新しいスープは (Italian vegs. なぞは) 具が水面近くに浮いていることが多い。 これが時間がたってくると沈んでくる。と、いうよりは、 たぶん表面にある具をみんなとっちゃって下のほうにあるのしか残っていない 状態になるのね。ああ眠い眠いもう寝ちゃおうか。
こういう「朝早く起きすぎて困る状態」というのは 何がいちばん困るかというと、身体は起きているのに 脳はまだ寝てるんである。だからなんとなくフワフワした状態になっており、 大学に出てきてもヤルキー君がまったくない。 だからもうこのボケ〜っとして時間だけが過ぎていくというこのあのアレきわまる状態になってるわけでして、
ケッキョキ (結局)。
まあどうでもいいんだけどよう、 …だめだ。書くこと忘れた。
ところで今きたメール:
Subject: 在ニューヨーク総領事館]【緊急メール】病原性大腸菌Ｏ１５７感染の流行、終了
＜＜＜緊急メール＞＞＞
在留邦人の皆様へ
当地における病原性大腸菌Ｏ１５７感染流行の終了について
２００６年１２月１９日
...
いまだにこんな懇切丁寧な連絡をくれる国の領事館がどこにある? すばらしい日本国。きっとオレがイクラで遭難しても自衛隊を出して助けてくれるにちがい
ない。
どうでもいいけど、今日だったらしい。 というか「中国では日付が進んでいるので昨日になる」という理屈。 なんだそりゃ。
どっちもありえないが。
ウソくさい真実と、
真実くさいウソ
そういえば、米国では電車の「中吊り広告」というものを見たことがない。 これははたして存在するんだろうか?
ってゆうか、オレは wikipedia なんか見てないで仕事しろ。たまの日曜に。 タマは関係ない。
さて問題です私が作製しようと考えていたのはなん
でしょう。
うんねこねーん、うんねこねーん。(ネコ目ネコ亜目)
せっかくなので記念撮影。 左上から、保険証、guggenheimの会員証、nyplのカード、右上はキャッシュカード (クレジット兼用)、 MTA地下鉄回数券、PATH回数券、NYU の学生証。
~/.python_history
とゆーファイルに残してあるのだが、1年前のものと比べてみた。
~/.python_history : 5692行
~/.python_history : 7017行
↓ ここに、あなたのお気に入りの言い訳を入れてください ↓
[ ]
あーわかったわかった。トップダウン主義者にはもううんざりだ。
でも、一般的にいって、 疑問をもつことは最大の攻撃だ。 何に対する攻撃? 何もかもに対して。 その意味で、オレも攻撃的な人生を送りたいもんである。 新山は疑問に対してはかなり粘着質で、 解決されない疑問をずっと「ためこむ」性質があるんだけど、 このぶんだとそのうち破裂すんではないかと心配。
新山はたぶんきっとおそらくもって脳味噌が少ない。しかし「脳味噌少なめ」というのは政治的に公正でないので、 これからは「脳味噌がチャレンジドな人々」ということにしよう。
使用例:
もう寝る。
しかし個人的には「自由なソフト開発」をしたけりゃ実名でソース公開しろと思う (そしたらツウちゃんねるでは敬遠されるだろうけど)。 というか、それまではコソコソやってたのに、 「裁判になったとたんに堂々としだす」ってのがなんかチグハグな感じすんだよね。 居直りと思われても仕方ないと思う。
ながのけん人にとって、false positive と false negative という概念は重要だ。
x="abc" y="def" z="pqr" ...
というような文字列をとる予定らしい。
オレは abc の中に " 自身が含まれたらどうすんだ、と尋いた。
この入力は外部から (人手によるチェックされずに) 与えられるので、
どんなもんが来るのかは前もって正確には予測できない。
普通ならバックスラッシュでエスケープだわな。(これは解析しにくいんで個人的にはキライだけど)
だが彼女いわく、どうもしない。たとえそうなっても、パラメータの順序はあらかじめわかっているので、
x="abc"" というのがあっても次にくるはずの y= を
探せばなんとかなるだろう、という。
ダメだよ。もし x の中身が a" y="b でかつ
z の中身が c だったら、その外部表現は
x="a" y="b" z="c" になる。
これでは x="a" かつ y="b" かつ z="c" なのか、
x="a y="b" かつ z="c" なのか、
あるいは
x="a y="b" z="c" なのか、
曖昧になってしまう。
…と言ったら、そんなことはまず起こんないから大丈夫だ、という。 あのねー。…たいていこういうヤツがブチこわしにするんだ。 ここは重要な部分なんでしょ? しかも人手を介さずに動くところだし。 ある種の感覚のない人々はこの手のシステムを設計してはいけない。
この手の話題では昨日べつの人と話してたんだけど、 機械の故障とソフトウェアのバグはぜんぜん違うという話。 機械はモノでできてるので、それはある日、必ず壊れる。 だから機械を設計するときは「ここは絶対にこう動くだろう」ということは 言えなくて、すべて確率でしか言えない。だから機械の設計ミスというのは、 その見積りが合っていなかったということになる。ところが ソフトウェアの場合は「ここは絶対にこう動く」と言いきれる場合があるのだ (CPU がちゃんと動いている限りは。もっともこれはたいして保証されているわけではないけどね)。 デカくなるとさすがにそれは難しいけど、単純なものだったらそのふるまいは 数学的に証明できるんで、非常に重要とわかってるコードでそれをしないのはアホだろう。
(追記) じつはこの形式を決めたのは Ralph だったらしい。 脱力〜。
こないだの tar の話のつづき。 bsddb でも gdbm でも「なんか、気にいらない」のは、 レコードを書き換え可能にするために、領域管理を自前でやっていることである。 つまりレコードが伸びたから新しくファイルを伸ばそうとか、 このレコードが削除されたからこの領域を再利用しようとかいった話。 でも、ほんらいこういった領域の確保や解放はファイルシステムの仕事なんだよ。 何が哀しうてそれをまた 1ファイルの中でやんなきゃいけないわけ? そりゃスピードが非常に重要な局面で、システムコール 1回でも時間が惜しいっていうことはあるだろう。 じっさい、Oracle の人々はファイルシステムをバイパスしてディスクに直書きすれば もっと最適化できる思っており、「OSは余計なことしてくれるな」っていう立場だ。 でも、うちら一般人はすでにある枠組みでオッケーなことが多いんだから、 なにも同じことをまたいちいち繰り返さなくてもいいと思うけどなあ。
ぬっくり。(脱力する音)
tar でいいじゃん」という結論に達した。
制約条件は以下のとおりである:
と、いうか、制約 g. はかなり重要で、
これを満たそうと思うと使える候補はかなり限られてくる。UNIX 標準ツールでなんとかなる
アーカイブ形式といえば tar か、ar か、cpio か、あとは shar ぐらいしかない。
「ファイルシステムそのものを使う」という手もあるが、
旧来のファイルシステム (= ext3) ではファイル数が増えてくるとアレしてくる。
zip は標準とはちょと遠いし。で、最初は「書き換え可能」というのを目指していたのだが、
tar だと中のファイルを後から書き換えたり、削除したりはできないのだが、
別にできなくてもいーじゃん、ということにした。
なぜなら「中身はしょせんテキスト」というところが重要である。
つまり、どうせ Wiki やメールなんだから、書きかけだろうが書き損じだろうが、
ぜんぶ途中経過を残しておきゃいーじゃん。どうせ 1レコードは小さいんだしさ、
書き換えたら新しいレコードとして追記しちゃえばいいワケよ。
さらに、これは RDBMS である必要がない。文字列検索やその他のインデックスは、
本体ファイルとは別にあとから構築すればいいんである。重要なのは、
「この tar ファイルさえあればすべての情報を再構築できる」ということであって、
これ以外の情報はオプションでしかないようにするところだ。ようするに SQL ダンプみたいなもんだが、
データ記録用としてはこれは非効率すぎるので、tar というわけである。
さらにさらに、Python には tar を読み書きする tarfile モジュールがすでにある!
とゆうわけで、tar をデータベースとして扱うような wrapper を書けばいい。
実際には他にも問題はいろいろあるのだけど、それらについては「外側」の解決策で
なんとかなると思う。
大事なメールやら日記やらを BSDDB とか InnoDB に任せられるかってんだ。 そもそも、オレはどっちのソースも読む気しないぞ。 もっとも ext3 のソースも読んだことないけど、そこまでパラノイアじゃないんで。 …とはいえ、ext3 のほうが InnoDB よりはるかに信頼性は高い (と新山は勝手に思っている) にも かかわらず、どちらもソースを読む人はほぼ同じくらいしかいないんではないかと思われるが… これは問題さね。
おかいしいですか?
(>_>)
(<_<)
$ telnet www.baidu.com 80 Trying 202.108.22.44... Connected to www.baidu.com. Escape character is '^]'. Connection closed by foreign host.
しかし本当に面白いのはここからである。 この TCP の接続切断は Baidu 自身がやっているわけではない。 じつは中継するどこかのルータで、Baidu からくる TCP パケットの直前に TCP の reset パケットが挿入されているのだ! Baidu が送ってくるもとの 検索結果をふくんだ TCP パケットは、じつはしっかり米国まで届いている。 しかしそれよりも前にクライアントは (中華ファイヤーウォールによる) TCP reset を受けとってしまうので、接続が切れたと勘違いして 以後の受け取りを拒否してしまうというわけである。頭いいね。だからクライアント側の TCP に細工をして (実際には clik というプログラム可能なルータを使っている) この reset パケットを無視するようにすると、まんまと Baidu の検索結果を 受けとれるらしい。なぜこんな仕組みになっているのかというと、 おそらく返りの TCP パケットぜんぶを中華ファイヤーウォール側で (選択的に) ブロックするのは コストが多きすぎるからだという。それに中国政府としては、あくまで検閲は 秘密裏にやってることにしたいので (バレバレだけど!) 「なるべくネットワーク障害のように見せたい」という思惑もあるようだ。 しかしこれはあくまで軽度の検閲であって、検索結果とサイトの組み合わせによっては 重度の検閲もあるらしい。その場合には TCP まるごとブロックの刑や、 24時間ブロックの刑も適用されるとのこと。それ以上の重罪になるとどうなんだかは知らない。
ほかにも、TCP パケットからストリームの再構築まではやっていないらしく、 「検索文字列がすべて 1パケットに含まれてないと反応しない」という制限があるらしい。 だから TCP のウィンドウサイズをめちゃくちゃ短くして、たとえば "falu" と "n gong" のように 切れるようにしてやるとひっかからないという。意外とアホね。このぶんだと gzip 圧縮された 応答もムリだな。しかし中国ではこのようにほとんどすべての情報が検閲されてるのだが、 たとえば google.cn のようなサイトは ふつうに検索可能である。 なぜならgoogle の検閲力は中国政府のお墨つきだからである。 しかしたとえ Baidu のように中国国内・国外のサーバが何も考えずに検索結果を返してきても、 中国政府はしっかりブロックできるようになっているのだ。毛主席万歳ですなあ (意味不明)。 こういったファイヤーウォールの さばけるトラフィックはどれくらいであるのか? …と聞いてみると、彼らによれば、まだはっきりとはわかってないものの、 すーんごく高性能らしい。ただ今のところ定量的に測定した事例がないので、 彼らは将来的に一種の“検索 DOS 攻撃”を米国側からしかけてこれを測定する計画だという。 前には、この研究のために、 もしかすると VPN かなにかで中国国内のマシンを使えるかも? ということだったが、 結局できなかったらしい。同様に中国内のマシンを使って検閲を調べる Harvard Law School の 「検閲確認プロキシ」も有名だったが、これも中国側のマシンが差し止められたのか、 いまでは使用不可能になっている。いずれにしても、中国がすんごいシステムを構築していることはたしかだ。 だから米国内のネットワーク研究者の間では、これは“悪のシステム”には違いないが、 悪ながらたいした業績と認めざるを得ない、らしい。 まあ原爆も悪だったが、たいした業績といえば業績だもんな。(論文いっぱい書けそうね。) 研究者というのはこんなもんである。 実際、こんなことが中国だけの技術力でできるはずはなく、ここにはさまざまな米国企業が からんでいる。たとえば、Cisco 様ですよ! 去年から今年にかけて、 中国は cisco のルータを少なくとも 200台ほど購入した記録があるらしい。 まあ、MS とか某 no-evil 社とかもそうだけど、 そこまでして市場が欲しいのかねえ。そしてここでは基礎技術として、ネットワークもさることながら、 『自然言語ショリ』とかいうのが大いに幅をきかせてるに違いない。 まあ、spam のフィルタリングよりは簡単そうだけどね。っていうか、 これはある企業のある人からオフレコとして聞いた話だが、ある企業では この手の技術 (ってどんな技術だ?) の応用として、メールサーバに設置して 社員がメールを私用に使ってないかどうか監視するシステムを売っており、 しかも高いのにそれが結構売れているらしい。ふうーん。 いやー自然言語ショリって儲かるんだなあ。
あ、ここでの企業ってのは日本の企業です。念のため。 ここで一句:
ふり向けば
みんななかよし
毛主席
Document ID: 349bec44c0d841e6cf0dcfd232595cc4
Yusuke Shinyama