_ _↓_ _ _ _ .
ア〜〜“〜〜““こんなんざダメだ!! (あした早起)
(まあ、しかし、「馬鹿クライアント」ってのは すでにべつのところで頻繁に使われてそうな用語ではある)
(ひさびさの) nylug みーてぃんぐ。 きょうはデータのアーカイブに関する話だった。 Evan さんはアーカイブ用クラスタを専門に売ってる会社の人で、 Archivas.com とゆーところ。 彼によると、 近年アーカイブは米国の企業にとって必要不可欠な技術になりつつあるそうな。 なぜなら書類の保存期間が法律で定められるようになったからだ。 これらは裁判の証拠として使われるので、企業にとっては死活問題となる。 じっさい、すでに今年になって多くの会社でアーカイブ関係の不祥事が発覚している。 たとえば Morgan Stanley は過去の電子メールを消していたために裁判に負けて 数十億ドルの損害を出した。CitiBank や Time Warner もデータ損失で 何億ドルも失っている。で、バックアップとアーカイブは違うという話。 バックアップはデータがダメになった場合に備えて短期間の状態を保存しておくものだが、 アーカイブは何年も前のデータを恒久的に保存しておかねばならない。 しかし、彼がいうには「アーカイブはつねにオンラインでないとダメ」だというのだ。 なぜか? 結局、磁気テープにバックアップして棚に積んでおくだけでは、 いざ弁護士がきて、これこれこういう電子メールを探せ、といったときに 間に合わないのである。さらにアーカイブは一回きりの作業では決してないという話。 メディアには耐久期限があるし、そうでなくてもいろいろと壊れる。 重要なデータの場合は二重化しておく必要もある。アーカイブは これらの現象にもつねに注意していなければならず、したがって ランニングコストがかかるのだ。そしてアクセシビリティも重要とのこと。 まず、ファイルは全文検索できなければならない。それから 考えられうるさまざまなメジャーな形式でアクセスできるようにしておく必要がある。 なぜなら、プロプライエタリなフォーマットやハードウェアを使っていたとして 万が一サポート会社がつぶれたらどうなるか? さらに何年もたったらどうなる? おまけに、情報にはセキュリティが必要だ。さらに、書類によっては、保存期限がすぎたら 意図的に破棄しなければならない。これには電子シュレッダーのような操作が必要で、 米国ではこれは DoD のなんとかかんとかいう基準を利用している。 そしてこれは自動的に実行されるのが望ましい。こうしたことを考えると アーカイブに対する要求は結構シビアだ。専門の会社が存在していることも うなづける。ということでわが社の製品なのです! という話の流れだったが、 とくに技術的につっこんだ話があるわけでもなかったので、 飲み会には出ず。42st. で吉野屋くって帰ってきた。 だいたい新山はいつも飲み会に出るかどうかは、 「おもろい話が聞けそうかどうか?」で決める。 LispNYC のミーティングはこの点ハズレがないが、 nylug の場合はビジネスっぽいときがあるからな。場所も TGIF だし。 どうでもいいけど 57丁目の IBM の守衛のおじさんは毎回同じ人で、 もう顔をおぼえてしまった。(もちろん向こうは知らんだろうが)
google://チョッキンナー/ (38件)
教訓: 一度ひろげた風呂敷は広がり続ける。
こういう場合、適切な関係というのは 大学が「問題を発見する側」で企業が「問題を解く側」なんじゃないだろうか? という気がする。しかしほとんどの場合、いまの大学は問題を発見してもいない。 何が問題なのかわかっていないんだろ。
てくるで、NY でおすすめな 3大ファーストフード:
ポイントは、これらは「ファーストフード」ではあっても 決して「ジャンクフード」ではないことだ (いや、Dosa はファーストフードとさえ呼ばない、いつもいってる Dosa屋の屋台には "Slow Food" と書いてある)。だから ハンバーガやホットドッグなど真のジャンクな物品はこれより無限に下に位置する。 実際、味的にいっても、たとえハンバーガーが世界最高レベルの贖罪を使ったとしても Kebab には勝てないだろう。しかもアメリカンは牛肉じゃねえか。 おなじ狂牛病の危険があるなら吉野屋のほうがまだましだ。 ほかにも焼きそば (チャイナタウン) とかクレープとか売ってるとこあるけど、 やっぱしこの 3つがいいね。
(ぜんぶ実話です)
おくればせながら、今年の豊富: 誰にも理解できない内輪ウケ (自分にも理解できない) を支えること。
socket.recv には、MSG_WAITALL がないとゆうこと。だー
/etc/hosts に 127.0.0.1 で定義されていた、
とかいうウヒャ〜な状況だってある (実際、あった)。そういうときに、すぐさま
「ここか? そんじゃあ、こっちか?」と原因を思いつけるようでないと困るし、
それは特定のディストリビューションに依存してはならない。
つうか、最悪の場合は rc や inittab から
たどって何がどこに設定されてるか理解できないとね…。
特定のディストリビューションだけを出題する理由は
それにロックさせたいからだろうけど、こういう広い範囲にわたる
問題解決を単純な選択式の問題などで試験できるとはとうてい思えない。
最低でも記述式でないとダメなんじゃないの?
しかしどのみち管理者の適性というのは (その時点での) 知識とはべつのところにある、 ように思える。
てくるで。
雨なのよねえぇ。きょうは午後じゅうザぁーザア降っているが、 外へ出てみたら風は熱風だった。風は象牙色で餅はガラスのいろ。 このぶんだと、夜もちっともすずしくなんないと見える。 どんこど、どんこど。
コレいつやむのよ?
(追記: 「風は象牙色」ってなんかヘンだよああ…と思っていたら、「壁は象牙色」だった。 造芸楼ってなに?)
!、||、&& のかわりに not, or, and が使えない。
C++ では使えるのに!
ところで「桜」と「楼」の字は別ではないぞ!
うわーーー、これ。世にもおそろしい言葉の暴力。
こういうのに気づいてない人にかぎって、 「死ね」とか「クソったれ」という言葉には分館だ、 いや、敏感だ。
大学から出るときまた雨がドシャぶっててヤーな一日だった。 まったくよう、日本じゃツユツユしてないってのに 梅雨がない(はずの)国でこの雨はなんだ!
てくるで、昨日書き忘れたこと。ひっさしぶりに Jason に会った。 あいかわらず訳のわからん会話。英語が理解できてもヤツの会話は理解できない。 ようするにこいつは Seinfeld に出てくる Kramer なんだよ。
きょうは午後になってアツい時分になぜか甘いアイスコーヒーがのみたくなり、 近所の Dunkin' Donuts へ論文を持ってでかけた。PowerBook も持っていったが、 一度も開かず、ただ運動用の「おもり」として作用しただけだった。 店内はとくに人がいなかったが、そのうち、一人のおっさんが 新山のテーブルに近づいてきてななめ向かいに座った。 歳は 40〜50。中東系。新山が論文を読んでいるのをじっと見、 そのあと「ペンをかしてくれ」というが、なんだか目つきが微妙に落ちつかない。 そのおやじが書いている書類を見ると、 "Dunkin' Donuts / Employment Application" と書かれていた。 このおやじ、ここでバイトすんの? その申込み書をいまここで書いるというわけか。 しばらくするとどこかへ消えて白人のねーちゃんをつれて現れ、なにやら質問をうけていた。 「あんた刑務所いったことあんの? 逮捕されたことあんの? え?」という質問に、 "yes, no" などとはっきりしない答えを言うおやじ。てゆうか、 なんでわざわざオレのとなりでやってるわけよ? しかも、ねーちゃん大声でマルぎこえ。 そのあと白人の店長らしき男が来て、「国籍はあるか?」「職歴は?」などと尋ねているが、 この中東系のおやじの英語がなんだかおかしい。とくに大したことでもないのだが、 なんとなく印象にのこったできごとなので書いておく。 (ふだん印象にのこったことというと、だいたい「ムカつくこと」なのだが、 今日はとくにムカつくことがなかったのでこのような文章になる)
あっ。調子もどってきたかな?
さて、ようやく pyvnc2swf ができてきたのだが…。
おそい。
なんだこれは。ほとんど画面のアップデートに追いつかん。
しかし考えてみればこれは予想できたことでもある。
vnc からくるピクセル情報というのは、たとえば RGB が
「青 6ビット、緑6ビット、赤4ビット」のように圧縮されているのだが、
これを Python でわざわざ 1ピクセルずつ展開しようとしていたのだ。
で、これはビット操作であるから、たとえば big-endian の 16ビット値が入ってきたとして、
ここから RGB 情報をとりだすためには一回 unpack してから
(((x>>10) & 63) << 2, ((x>>4) & 63) << 2, (x & 16) << 4)
のようにしなければならず (RGB のタプルに変換)、これをあとでまとめて再び文字列に pack し、
全ピクセルを join して pygame に渡していた。こりゃあトロトロして当然なわけだ。
画面サイズが 640x480 とかだと、この作業は何万回とくり返されるわけだから。
やっぱし、こういう大量のビット処理なんかは C のほうが向いてると思う。
でも VNC にはクライアント側で「このエンコーディングで送ってちょ」というのを指定できる機能があるので、
最初から無理にサーバ側のエンコーディングに従わなければよかったのだるが。
あと、Python profiler って使ったことなかったんだけど、使ってみようかな?
Profiler を使わなくても目で見てあきらかに遅そうな箇所がある。
たとえばこんなのだ:
これはピクセルのエンコーディングを SWF 用に変換するところなのだけど、
やっぱりこういう独立した文字列作成 + join をいちいちやってちゃマズいんだろうな。
C の配列のように in-place で置き換えればずっと速くなるのだが…。
array でも使ってみようかシラン。
data = ''.join([ data[i+2]+data[i+1]+data[i] for i in xrange(0, len(data), 3) ])
todo: とそかん。
ニューヨウクには何万人も日本人がいるから (たぶん)、 長野のニュースを日々チェックしている人間はオレ以外にいてもおかしくはない。 けど人数はそうとう少ないと思われる。
vnc まわりを改造して、クライアントからエンコーディングを 要望する「決め打ちエンコーディング」にしたら、そこそこの速度になった。 なんだ、はええじゃねーかよ! しかしなぜ自分がバカ正直に Server encoding に従うようにしていたのか 思いだした。vncrec の形式に対応するためである。こっちはすでにあらかじめ録画されたものなので あとからエンコーディングを変えることはできないのだった。でもすでに録画されたやつを swf に変換する場合はタイミングを気にしなくていいので、これはこれで残しておいてもいいな。 ところで、電車ん中で powerbook を開いてプログラミングしていたのだが、 「君、それ、言語なに?」ととなりの太ったおやじから尋かれ、そのおやじは こちらの席をかなり圧迫していたので、かなりムッとした答え方をしてしまった。 こちらでは電車で作業していると周りから画面を覗かれいろいろと質問をうけることが多い。 Keynote を使ってプレゼン資料つくってたときは黒人のねーちゃんから、 「なにアンタ、グラフィックデザイナー??」とか言われて脱力したし、 ほかにも日本語表示してたら「おマエのパソコンは日本語と英語をどうやって混在させてるのか」 などと尋かれ、そんなことどうやって説明しろっていうんだ?!
…ということで、いつもの日本食料品店へいってコンビニ弁当然としたものを 買ってきてしまった。中華料理などがダメなときでも、ふしぎと日本食だけは入る。 しかし「その気になれば弁当を買える」というワザはニューヨークならではだ。 他じゃできないだろうな。 もっとも一番いいのはやはりサッサと日本に帰ることだが…。
だいたい新山はあまり East villege がすきじゃない。 とくに土曜日の夕方などは、アイデンティティの崩壊した 若者 (日中韓国人、アメリカ人含む) で混みあっていて気分悪いからだ。 St. Marks Place なぞを歩いていると、携帯電話をもって 日本語でなにか大声でわめきながら歩いてる物体に出くわす。 まあここにいる中国人や韓国人も異常さでは似たようなものだが、 彼らはいつも声デッカイのに対して、なぜ日本人は外人相手には蚊のなくような 声でしかしゃべらないのに、日本人相手にはこうも大声でがなりたてるのだろう?
しかしこういうところに来ると「幸せな生活とは何か?」ということについて 改めて考えてしまいますね。
まあ、どうしても新山は都会 (日本であれ米国であれ) の生活というのが 楽しいとは思えないのだ。東京にもニューヨークにもこれだけ住んでみて まだイヤなんだから、こりゃあもうどうしようもない (あとは上海とパリにでも住めば完璧か?)。 もっとも、都会の生活に「慣れる」ことはできる。住めば都ってやつですよ。 しかし、こんなのは絶対に“都”じゃないと思う (はい、矛盾)。 なぜ人が都市へ「観光しに」来るのかも謎だ。オレが旅行者だったら、 ニューヨークなんかまっさきに無視するところなのに…。しかし、 まあ、こういう経験は、自分の中で「将来はこういう生活をしたい」という 計画を考えるのに役に立ったとはいえる。つまり、もう絶対に都会にあこがれる必要はない ということだ (もとから憧れてなかったけど)。と、いうか、都会が好きな奴っていうのは 永久にメニューを選んでる人間のような気がしてならない。
しかし、くりかえすようだが、くりかえしているが、くりかえすとみせかけてそうでないようではいてもじつはそのじつくりかえしにしかなっていないといういみでのくりかえしももうあきた。しかしながら、外は暑い。読み飛ばした奴はもう一度行頭にもどりましょう重要な秘密がかくされています外は暑い。 この週末からじわじは暑くなっていくの予定。もうやだ。
新山としちゃめづらしくバラを買ってみたのである。 基本的に白で、ふちの部分が淡いピンクっぽくなっている品種。 なんとなく出来心で買ってしまったが、高かった。 これで持たなきゃ承知しねーーからな。しかしやはりなんとなくバラは あまり好きじゃない。なんか、この形状が不吉な感じ。
nyu.edu の DNS 空間は世界中にちらばっている 300近いネームサーバ (root-servers.net 含む) によって握られている。よって、このうちのマシンが一台でもクラックされれば .nyu.edu ゾーンは 原理的には詐称可能になる。その中には berkeley.edu や ucla.edu、duke.edu のほかに、 dec.com(!) や it, fr, se, no, ch, au, nl, uk, ar などのドメインのサーバも含まれる。
同じことは columbia.edu などにもいえる。cam.ac.uk はもっとひどく、 400近いネームサーバが関連している。で、調べているうちに偶然発見したのだが、 じつは nyu のネームサーバは cam.ac.uk の名前に関係していた! その経路はこうなっている:
stanford.edu や mit.edu, rutgers.edu などはこんなに末広がりな構造には なっておらず、関連するサーバはせいぜい 30数個である。 これらのほとんどは tld のサーバなのでまず大丈夫だろう。 ほかにも Yahoo や Google もそう。とくに Yahoo に関しては Akamai 経由なのにわりと統制がとれている。
ちなみに tabesugi.net は dyndns.org 経由で、もろ glueless なので 関連するサーバは 50個でした。うちも固定 IP がもらえれば dyndns なんかやめて さっさと in-bailiwick なサーバにするんだが。
(追記: ちなみに cs.nyu.edu のネットワーク構成ははっきり狂っており、 うちには学科の DNS キャッシュが 3つあるのだが、そのうちのどれもサブネットの外側にある。 つうかこれ、建物が別だと思う。やってらんないのでローカルで勝手にキャッシュあげてますけどね。)
ちなみに、わざとです (ろ)。
todo: 英語の説明ページをつくり, LWN および Slashdot の編集者に href入りの RSS がもらえないかどうか打診してみよう。
てくるで、KKK のことを中国語で「三K党」と呼ぶことを知った。 このほうがずっとわかりやすいじゃん! で、その 3つの K とは何なんだ? 「奇妙・危険・キチガイ的」かな。 いや「詭弁、強弁、キチガイ的」のほうがいいかな。ゴロ的にも。
スズの値 (= teh value of Sn) が聞こえる。
しゃん しゃん しゃん しゃん しゃん しゃん しゃん しゃん しゃん しゃん しゃん
♪ ある-ぶl-こげな-がれ-からま-がれ-げら-らばだ-かば〜
(どことなく、アラブ風の歌)
嫌いじゃないぜ、君。
いうまでもなく、これは米国で 5セント硬貨がニッケルになってから生まれた言い回しである。 出所はどこなんだろう?
Python-cdb の場合:
db = cdb.cdbmake("foo.cdb", "foo.tmp")
db.add("abc", "123")
db.finish()
db = cdb.init("foo.cdb")
print db["123"]
db.close()
CL-cdb の場合: (finish, close が必要ない)
(with-cdb-make (db "foo.cdb" "foo.tmp")
(add db "abc" "123")
)
(with-cdb-init (db "foo.cdb")
(print (getitem db "123"))
)
実際にはこうなってるわけですけどね:
(defmacro with-cdb-make (args &rest body)
`(let ((,(car args) (cdb-make ,@(cdr args))))
,@body
(finish ,(car args))))
Ruby 信者ならブロックを使って似たようなことをやろうとするだろう。 ただし、Ruby のブロックはマクロとはまったく別の原理によるもので、 無理に (順序が逆だけど) Python でマネするとこうなる:
Python の場合、エセブロック風味:
def mymake(db):
db.add("abc", "123")
with_cdb_make(mymake, "foo.cdb", "foo.tmp")
def myread(db):
print db["123"]
with_cdb_init(myread, "foo.cdb")
def with_cdb_make(proc, cdbname, tmpname):
db = cdb.cdbmake(cdbname, tmpname)
proc(db)
db.finish()
return
こういう場合に Python の欠点となるのは「なんでも名前が必要なこと」だ。
lambda も廃止されたし (新山の中ではすでに廃止されたことになっている、今年の 4月1日以来)、
匿名の関数というものが許されないのである。ただ、いつもいつも新しい名前をスコープに導入するのは
気分がよくない。これでは特定の領域だけで使いたい名前というのがあるときにも Python ではいちいち
名前がそのままスコープ中に残ってしまう。これが気持ちわるい。
現在では名前をある時点で消すには del をつかって明示的に
削除するか (これはどう考えても美しくない)、def を
使って新しい関数をつくってやるしかない。
C の { 〜 } みたいなのが欲しいな。(← 矛盾 →) でもこれ以上新しい機能を増やさないでくれ。
べつに今やっている仕事では cdb は関係ないのだが、研究で使うつもり。なぜなら いまは GLARF の起動時に辞書の hash-table をメモリ上に構築しているのだけど、 こいつが遅くて気に入らないのだ。あと、今ではもうだいぶ「Lisp流儀」に慣れてきたので、 もうちょっと Adam のコードを Lisp っぽくできるだろう (Adam のコードはほんとに基礎的なレベル)。 今のところはうちで GLARF を使っているのは新山だけなのだが (去年まで Shubin が使っていたが彼は卒業してしまった)、 今後 Ralph やへれんも使う予定らしいので、このへんを きちんと整備しておく価値がある。ははあ、なるほど。
しやし (= しかし?) やはり Lisp ではいろいろと戸惑う。
まず、CommonLisp の関数はめちゃくちゃ沢山あるので、
「こういう関数が絶対どっかにあるハズなんだが」と思っても
みつけるまでにひと苦労する。新山は HyperRef を使っているが、
HyperRef でも CLTL でもリファレンスがすげー使いづらい。
なんかあるとすぐに Glossary に飛んじゃうし。
おまけに Lisp は妙なところで拡張性があるくせに、
単純なことが以外とめんどうだったりする。たとえばバイト操作。
CommonLisp の標準にはいわゆる「ビットシフト」がない。
つまり Python でいうところの >> がないのである!
しかし、そのかわりに dbp と ldb というもっと大がかりな関数があり、
ある数値の特定のビットをいじるための枠組みを提供している。
でも、オレはビットシフトが欲しいんだっての!
ファイル操作もかなり不格好だ。たとえばファイルを開くための
open という関数があるが、例外動作を
こと細かく規定できる。たとえば、すでにファイルが存在していたときに
オープんしたときの挙動を「エラーを返す / nil を返す /
新しいバージョン番号で作成 / リネームする / リネームしてから削除する /
既存のままでオーバーライドする / 追記する / truncate する」
の中から選べる。おまえは COBOL か?
それから、型変換がかなり変態で、ある関数では array → list への
暗黙の変換が行われるのに別の関数ではダメだとか、
あと Python でいうところの struct に相当するパッケージが
なくて (あるのかもしれないが発見できなかった) エンディアンの差異を
吸収する関数をわざわざ自分で書かなければならなかったとか。
いちばん困ったのは loop である。
これ、たぶん Lisp の中でもいちばんフクザツなマクロなのだが、
マニュアルを見ても意味不明なうえに、web を検索しても
使用例がぜんぜん見つかんないのである。ようするにこれは
Python でいう for と while と
list comperehension (条件つき) を全部いっこにまとめたもので、
メチャ複雑。これを使ったほうがあきらかに簡単に書けるのに、
文法がよくわからん。結論: Lisp 嫌い。
しかし Lisp には絶対的な利点がひとつある。 それは Norvig もいっていたように 「(コンパイルすれば) あきらかに速い」ということだ…。 それに C の関数も直接呼び出せる (segfault の危険はあるけど)。 これだけ速ければ、もうアプリケーションレベルではほとんど C や C++ なぞ必要ないだろう。アセンブラレベルの処理が 必要なときしか使う機会がないように見える。 それでも、可搬性と手軽さという利点はあるか。
(追記: 調べてみたら cuny.edu とか columbia.edu も同じようなモンだった。 rutgers.edu はまとも。)
□□□□ (□□□□、)、 Firefox □□□□□□□□□□□ (↑) □□□□! □□□□□□□□? □□□□□□□□□□□□□□□□□□□□□□□□□!! (□□: □□、□□□□□□□□□□□□□□□□□□□□□、□□□□□□□□□□、□□□□□)
□□、□□□ー (□ー□□□□□□□□□ &)
google://□□□□□□□□/ (637)
(□□□□ Firefox □□□□□□□□□□□□□…)
□□□□、□□□□□□□□□□□□□□□□□□□□ □□□□□□□□□□□□□□□□□□ □□□□□□□□□□□□□□□□□□□□□□□□。 □□□□□□□□□□□□□□□□、 □□□□□□□□□□□□□□□? □□□□□□ー□、□□□。 (□□□□□□□□□□□□□□□□□□□□□□□、 □□□□□□□□□□□□□□□□□ □□□□□□□□□□□□□)
<div align="67%"> □□□□□□□□□□□□□□□□□□□、
□□□□□□□□。□□□□□。□□□□、□□□□□□□□□□□□□□□。
□□□□、□□□□□□□□□□□□□□?
(□□: □、table □□□□□□□□。)