もしオレが死んだあともこの日記が更新されてたらどうしよ?
たこヤキ
朝方から上の階のガキんちょが廊下を何往復もドタドタドタドと走り回っている。 とってもうるさい。30分ぐらいやってた。
「世も末だ」と思うことは結構あるが、 昔からずっと世は末だったのだし、これからも世はずっと末だろう。 とうぜんのことだ。というか、むしろ末が博士か世なのである。つうことは つまり博士じゃないから世だな。大和田さん、檀さん、大和田さん。 ってどっちなんだよ!! 以下りゃく
しかも、この 科学技術・理科大好きプラン ってのは、なんだっ! 誰かツッコめよ。
なんか、グチばっかり書いてるが、それが目的なのでまあいいか。
というかオレは本来もっと楽天的な性格なのであル。
たまにわ何か「これはイイ!」って内容のことを書かせろよ!!
いや、実際にはそういうことはたくさんあるのだけど、
どれも個人的なことなのでここに書けないのが多い。
なんしろ、ここはどうでもいいことダケを集中的に書くようにしてるんだからな。
どうでもよくないことは三クシイの日記に書いています!
ウソじゃありません!! 断
じて!!! !！!1
…断さん、太輪田さん、断さん。(つづく)
新山の語学力では、ボストンで何かの一周年を祝った、ということしかわからん。
ちなみに、これが広東語ではこうなるらしい:
新San1 华Waa4 社Se5 波Bo1 士Si6 顿Deon6 3 月Jyut6 31 日Jat6 电Din6(记Gei3 者Ze2 杨Joeng4 志Zi3 望Mong6)美Mei5 国Gwok3 马Maa5 萨Saat3 诸Zyu1 塞Coi3 州Zau1 港Gong2 务Mou6 局Guk6 3 月Jyut6 31 日Jat6 在Zoi6这Ze5 里Lei5 举Geoi2 行Haang4 活Wut6 动Dung6,隆Lung4 重Cung4 庆Hing3 祝Zuk1 中Zung1 国Gwok3 远Jyun5 洋Joeng4 运Wan6 输Syu1(集Zaap6 团Tyun4)总Zung2 公Gung1 司Si1“珍Zan1 河Ho4 轮Leon4”首Sau2 航Hong4 波Bo1 士Si6 顿Deon6 港Gong2一Jat1 周Zau1 年Nin4。
あのー、、5声とか 6声とかって何ですカ?? でもこっちのほうがたしかに日本語の読みに近いよね。
なんで中国語がキレイに聞こえるかっつうと、たぶん一語一語の長さがほぼ固定長 (というか、量子化されている長さ) だからなんじゃないか。日本語だとこうはいかない。
あー、いま見たら Lynx でも (EUR) と表示されてら。
おめでとうございます。
ヒョーヘュッショグング (heohasshewngng) を知っているかね? 性格を変えるのは大変だ、ということだ。大変だ、ということ。
久しぶりにヘンな夢を見た。 どこかの湖畔に高層ビルが何本か立っており、 新山はその間をプカプカ漂っている。 飛行しているというよりは、風で流されているという感じ。 なにか気球のようなものにつかまっているのだが、それは非常に小さい。 動力は謎。で、そのビル群のなかに非常に古くなって、もう使われていないビルが 風でグラグラ揺れていたので、近くを通ったついでにちょっと押してみたら、 これが本当にただ「石を積み上げただけ」でできており、ビル全体が 横向けにバターんとひっくり返りやがった! ちょうど隣にでかい空き地があったので、 ほかの建物にぶつかるということはなかったのだが、 新山は「やべーー、逃げよ」と思い、街の外のほうへ向かう (なぜかこの時はコントロールがきいたようである)。 その都市のまわりには湖にそってずっとカラマツの林が続いていた (というか、湖と都市の周囲はすべてカラマツの林に覆われていた)。 どういうわけか高度が上がらず、地面スレスレで飛行し、どこか高い山の上に不時着する。 新山にはなぜかそこが長野のどこかであるという確信があり、 山をおりようとしたのだが、ふとここには山をタテにくりぬいて集合住宅がつくられているということを 思い出した (あいかわらずどっからこんな知識が湧いてきたのかナゾだ)。この建造物は やや斜面にそって半地下な状態でつくられており、規模はそんなに大きくなく、全部で 10世帯ぐらいである。 ここの各層に 2世帯ずつぐらいが入っており、オレはそこを階段で降りていった。 しかしどの家もひどくひっそりして人の気配がまったくしない。 ふもとまで来たあたりで住宅のひとつのドアが開いており、見るとそこは 「ちょっと人が出かけた状態」がもう何年も放置されたかのようなありさまだった。 で、それを見てふと「ここに住んでいた人はみんな連行されて虐殺されたのではないか」 という考えがうかび、どういうわけかそれは事実に違いないと思った。 それでゾっとした…ら目がさめた。
新山の夢は湖がでてきたり、山の中で起こるものがけっこう多い。 やはりこれは、原体験によるものが大きいんだろうか?
Firefox を起動しておくと、一定時間おきに aus.mozilla.org に接続する (しかも、クッキーつきで) ということを知ってたかな?
でも考えてみれば受験産業もコンプレックス産業かもしれない。 新山は英会話にはさほど金を使ってないが、これには金と時間を使いすぎた。 そしていまだにそのツケを払っている。
あ、晴れた?
つうか、今日一日の体力は使い果たしただろ。もう帰っていいすかね?
(UNIX-HATERS Handbook, P. 123 より)
X-Windows の悲劇50-MIPS ワークステーションを 4.77MHz の IBM PC みたいにする方法
もし X の設計者が自動車を作ったら、運転席には最低でも 5つのハンドルが隠されていて、そのうちのどれひとつとして 同じ動きをしないだろうね -- でもカーステレオでギアを変えたりできるかもしれないよ。 便利な機能だね。-- Marcus J. Ranum, Digital Equipment Corporation
X Windows は GUI界のイラン・コントラ事件である。 政治的妥協ともつれた共謀関係、誇大広告、そしてひたすら欲望の惨劇である。 X Windows とメモリの関係はロナルド・レーガンとカネの関係のようなものだ。 何年にもわたる『ブードゥー人間工学』がまるで前例のない途方もないメモリ不足を生み出した。 分裂的な依存関係、分散デッドロック、そして迷宮プロトコルなどが入り乱れて、 渋滞と、排他競合と、すでに広まったダブルスタンダードを一層深刻にしている。
X は、価格 5000ドルの便器と共通するところがある -- Sun の Open Look 時計のように。 これは 1.4メガバイトもの実メモリを消費するのだ! 22台の コモドール 64 から RAM を全部ひっこ抜いてきても、まだ時刻を告げるには足りないのである。 生の X11R4 "xclock" でさえ 656K を必要とする。そして X のメモリ使用量は増大しつづけている。
X -- 史上初の、完全モジュール化されたソフトウェア大惨事
X Windows は、 MIT CS 研 5階のオフィスにいたある男のプロジェクトとして始まった。 この男はウィザード級のハッカーで、W というウィンドウシステムに精通していた。 これは当時スタンフォードでやっていた V プロジェクトの一部として設計されたものである。 彼は分散型のグラフィック・ディスプレイサーバを作ろうと思いついた。 基本的なアイデアはクライアントと呼ばれるプログラムをある計算機で 走らせておき、別の計算機で走っているウィンドウサーバと呼ばれる 特別なプログラムに表示できるようにするというものだった。この 2台の計算機は ネットワークにつながれていて X プロトコルが話せるようになってさえいれば、 VAX でも Sun でもどちらでもよかった。
X は真空の中で生まれた。当時 Unix にはグラフィックスの標準というものがなかったので、 X はそういう標準を提供したのである -- しかもフリーの実装つきで。 X はほとんどのアプリケーションの敷居を上げた。みんなのハードウェアが、 突如としてフリーの MIT X サーバを動かすだけのものになってしまった。
今日でさえ、いまだに X サーバは速いコンピュータをアホアホ端末に変えてしまう。 X を高速に走らせるには、トンでもないハードウェアが必要だ -- ハードウェアメーカーが喜びそうなすごいやつが。
ノングラフィカル GUI
X は 3つのプログラムを動かせるようにデザインされている。
xterm、xload、そしてxclockである。 (ウィンドウマネージャの概念は後から考えられたものだ。) MIT で開発された最初の数年間、このウィンドウシステム上で走るプログラムは これだけだった。これらのうちどれ一つとして グラフィカルなインターフェイスを持っていないことに注意してほしい (xclock をのぞく)。 これらのプログラムのうちカット・ペーストらしきものを実装したのはたったひとつだった (おまけに単一のデータ型しかサポートされていなかった)。この中に洗練された カラーマネジメント機構を必要とするものはない。すると、近代的な X がたどりつくものは 結局これらがすべてなんだろうか?さて 10年が経過し、いまや X を動かしているほとんどの計算機は 4つのプログラムを走らせていた。 それらは
xterm、xload、xclock、 そしてウィンドウマネージャである。そして、ほとんどのxtermでは Emacs が走っていた! X は Emacs を開くためのもっとも高価な方法となったことは 言うまでもない。こんな文字ベースのアプリケーションを走らせるのに高価な ビットマップを買わせるよりも、カーネルに端末制御を任せればこれらは もっとずっと安価で簡単なものになっていたろう。そのかわりにユーザは これらのキタナイ文字を見られなくなっていただろうが、それはトレードオフというものだ。Motif 自傷キット
X は、それまでベンダが何年にもわたって欲しいと言いつづけてきたものを与えた。 それは異なる機種を相互に接続できるような標準である。しかし X はそれを十分な形では与えなかった。 X はプログラマにウィンドウやピクセルを扱う方法は与えたものの、そこにはボタンやメニューや スクロールバーなど、グラフィカルなインターフェイスに必要不可欠なものが欠けていた。 そこでプログラマーは自分で発明する。ほどなくして、Unix コミュニティは 6つかそこらの 異なるインターフェイス標準を持つようになってしまった。10行ほどのコードも書いたことのない 連中がマサチューセッツ州ケンブリッジのレンガ造りのビルに集まり、のちに失敗することとなった コンピュータ会社を設立し、「ソリューション」を考え出した。 それが Open Software Foundation の Motif である。
Motif が何をやるかというと、これは Unix を遅くする。ほんと遅いよ。 Motif の当初の目標は、1988年ごろの HP のウィンドウマネージャ 程度のウィンドウ管理能力と、Microsoft Windows 程度の上品さを X Window System に与えることだった。ちなみにこれは冗談ではない。
惨劇のレシピはこうだ: まず Microsoft Windows のメタファーから始めよう。 これはアセンブラで設計され、ハンドコーディングされている。 X の上に 3層か 4層のレイヤをかさねてこれを Windows みたいに見えるようにし、 それを "Motif" と呼ぼう。さて、ここに 2台の 486マシンを用意し、 1台では Windows を走らせ、もう 1台では Unix/Motif を走らせる。 どっちが息切れするか観察しよう。どっちが早くしぼむだろうか。 どっちのほうがロシア動乱より先に終結するだろうか。プラットフォームとして、 Motif は Macintosh OS や DOS/Windows には太刀打ちできない。
ICEキューブ: リーサルウェポン
X 基本設計のゴールのひとつが、ウィンドウマネージャをウィンドウサーバから 分離するというものだった。「メカニズムを提供し、ポリシーは提供しない」というのが中心教義だ。 つまり、X サーバは画面にものを描いたりウィンドウを管理したりする能力は提供するが、 ユーザインタフェイスについての特定のポリシーは提供しないということだった。 これは当時はよく思われたのかもしれないが (とりわけユーザが研究職で、インターフェイスの研究のために いろんなものをとっかえひっかえしている場合には)、実際にこれが生みだしたものは まぎれもないインターフェイス版バベルの塔だった。
ある友達の Macintosh の前に座って、シングルボタンのマウスを使ったとする。 それはたぶん問題なく使えるだろう。同じように友達の Windows マシンの前に座って、 2ボタンマウスを使ったとしても、たぶん問題なく使えるだろう。しかし友達の X 端末の前ではどうなるか。3つのボタンがあり、それぞれが異なった機能を 異なった動きで、しかもそれが日によって異なった方法で設定されている -- しかも、これはまだ Control-左ボタンとか、Shift-右ボタンとか、Control-Shift-Meta-中ボタンとかを 試す前の話である。プログラマの観点からみてそんなにいい話とは思えない。
その結果、X コンソーシアムからもっとも驚くべき文献のひとつが世に出ることになった -- それは "Inter Client Communication Conventions Manual" というもので、 通称 "ICCCM"、"Ice Cubed"、あるいは "I39L" と呼ばれている。 これは X クライアント同士が X サーバを介してお互いに通信するときに 従わなければいけない規約を定めたもので、そこにはウィンドウ管理から、 選択範囲から、キーボードとカラーマップのフォーカスから、セッション管理までが 含まれていた。一言でいえば、これは X の設計者が忘れていたものを 全部カバーしようとし、間違ったものをすべて一挙に直そうとしていたのである。 しかし時すでに遅し -- ICCCM が出る前に人々はすでにウィンドウマネージャや ツールキットを作ってしまっていた。そこで ICCCM は過去の失敗と 互換性を保つために歪曲を余儀なくされてしまった。
ICCCM の内容は信じがたいほど濃いものである。 これを最後の最後まで一字一句忠実に守らなければならず、それでも結局は動かない。 ICCCM への準拠は、X のツールキットや、ウィンドウマネージャや、たとえ 単純なアプリを実装するものにとってさえも、もっとも厳しい試練となった。 あまりに大変なので、これだけの労力を費やしてもそれに見合うだけの メリットがほとんどない。そしてもしひとつのプログラムがこれに従わないと、 全体がコケる。X でカット・ペーストが (ASCII テキストを直にカット・ペーストするのでない限り) まともに動いたためしがないのはこいつのせいだし、ドラッグ&ドロップすれば システムが固まり、カラーマップは決して正しいタイミングで切り替わらず、 キーボードフォーカスはカーソルに遅れをとり、 キーをたたけば間違ったウィンドウに入力され、 ポップアップウィンドウを閉じるとアプリケーション全体が終了してしまうのはこいつのせいだ。 もし互換性のある ICCCM 準拠なアプリを作りたければ、現存するすべての アプリケーションやウィンドウマネージャとクロスバーテストをし、 次のリリースでは問題を修正してもらうようベンダにお願いに行かねばならない。
要約すると、ICCCM は技術的な大事故だったということだ。 猛毒のいかれたプロトコルが大量投棄され、後方互換性の悪夢に悩まされ、 時代遅れの「問題未満」に複雑怪奇な「解決策未満」が与えられ、 大量のカサブタと爪跡によって業界標準の裸の王様の 倫理的・知的な悪行を隠蔽しようとしているのである。
こいつらツールキットを使うのは、マッシュポテトで本棚を作るようなもんだ。-- Jamie Zawinski
ちなみに「X-Windows」とあるのは前書きによれば 一部の読者をムカつかせるためのわざとだそう。 それいいな! これからはオレも uniX とかコミニュケーションとか書くことにしよう。。。
google://なら誰でもいい/ (96,300)
そのうちに。
<OYAGAG></OYAGAG>logging っていうモジュールがついてるけど、
スピードが重要な局面ではこれは複雑すぎて使いたくないんだよね。
同じように、debug() とかいう関数を作るのもやりたくない。
なぜならそれは
debug('fungee: %r' % x)
('fungee: %r' % x) の部分が評価されちゃうから。
これは結構時間がかかる。いっぽう、
などとしておけば、ログを出力しないかぎり実行時間はずっと少なくてすむ。 しかしどうしたもんだろうね。デバッグとif debug: print >>stderr, 'fungee: %r' % x
assert に関しては、
Python にもマクロがあればいいなあと思うよ。
\baselineskip\baselineskip\baselineskipバッファリングってなんんnのためにあるんたっけ?
バファリンとは何の関係もな
だいたいだな、いつも念入りに準備したプレゼンに限ってさっぱりウケず、 テキトーーーにやったやつがウケるというのはどういうわけだ。 むか津く。
(追記: きょう Citarella で買ったリンゴは蜜たっぷりで激ウマ。 いつのまにかすっかりリンゴの季節っすね。)
成長するにつれて、成長率が鈍化していくというのはたしかにあるだろう。 だが多くの人々は、すこしでも成長するというよりは、むしろ積極的に後退しているように見える。 これはつまり 30 をすぎたあたりから人間はまたアホな方面に 逆戻りするということか? つまりオレは放物線の頂点に近づいているか、あるいはもう過ぎてしまったかだ。 頂点がこんなに早くくるとは予想外じゃよ。
今日も風が強いです。フウが強い。フぅ。
一方で、もし「めくら」を部分文字列として含む表現がすべて放送禁止にされるとしたらおそろしいな。 「目くらまし」も言えなくなるし、そんなこといったら「オシ」はどうすんだ。 テレビ局は謝罪しまくりになるぞ。ああ、でも、いつもやってるのか。 いっそのこと、画面の下にいつも「只今不適切な表現を言っています」というテロップを出しておきゃあいいのに。 そうすりゃあ誰も差別のことなんか考えず、好き勝手に言いたいことが言えるようになるだろう。 理想的な社会とは差別を忘れられる社会のことだね! もっとも、差別というのは意識されなくなることが一番おそろしい差別なのだけど。 なにこれ? なにそれ?
(追記: 多くの人々はすでに忘れている)
(追記:
新山は実世界でも友達がほとんどいないので、ネット上でのこうした“<code>友達</code>”に
興味がないのは当然か。そもそも、友達を積極的に「作ろうとする」という行為がまったく理解できん。
政治家じゃあるまいし。
友達ってのは作ろうとしてできるもんじゃなくて、勝手に「できちゃってる」もんなんだよ。
ある人間について、オレはいつからこいつと口を聞くようになったんだろうなあ…と思っても、
ほとんど場合そのきっかけは思いだせないのだ。
そういやー新山の大学時代の友達は苗字が「サ」行で始まる奴が多いのだが
(スズキ、サトウ、サイトウ、セキグチ)、
これは明らかに物理実験の班分けが近かったことが原因だろう。このテキトウぶりを見よ。)
よくみるよね。
くりかえします。
「静電気は料理をおいしくするのでありま賞か?」
一瞬そう思った。一瞬そう思っただろ! 答えは、味噌汁だけが知っている。
ちなみにこのサイトは 3禁 (= 3歳以下の大人は閲覧禁止) です。
(軽パッチョ)
Phrase of the day: "debugging as autopsy" (検死によるデバッグ)
おれは 1時間以上も立ち話していたのか? なんとまあ。
きょうは network & distributed system の授業にでてきた。 Lakshmi (教授) は教え方がいい。かれはいつも授業のはじめに アルゴリズムを理解させるために簡単なオモチャを使ってみせる。 (オモチャといってもたいていは紙きれで、 裏紙をみんなの前でビリビリ破って使うだけなのだが。) こういうのはうまいなあ。 きょうは TCP の congestion control (渋滞制御) についてだった。 これは、以下のようなゲームとしてモデル化できる:
実は、ここでいう「モノ」とはある経路上のネットワーク帯域のことである。 各プレイヤーは ホストに相当し、プレイヤーが「モノを取る」というのは、 ホストが TCP パケットをひとつ送信することに等しい。 各ホストは相手ホストまでのネットワークの帯域 (供給される「モノ」の数) を知らないし、 他に何台のホストが同じ回線を利用しているかも知らない。 しかも、これらの数は時間によって上下する。プレイヤーが得られる唯一の情報は、 「モノが取れなかった (つまりパケット送信に失敗した)」 というペナルティ情報だけである。プレイヤーがモノをとりすぎた場合 (つまり、ネットワークの許容量を超えてパケットを送りすぎた場合)、 それらのパケットは drop するのだが、あるパケットが drop したという事実はすぐにはわからず、 しばらくたってから (ACK が返ってこないという事実により) 判明するため、そのあいだにパケットはどんどん無駄に送られ続け、 ホストは再送のための著しいコストを支払わねばならなくなる。 さて、ここですべてのプレイヤーが同じように行動すると仮定した場合、 全プレイヤーの取り分を最大化するようなアルゴリズムはあるだろうか? -- それが 4.3BSD の (そして、その後のほとんどの OS の) TCP スタックに内蔵されているロジックなのだ。
これは、基本的には各ホストが TCP のパケット流量を動的にコントロールすることによりおこなうのだが、 このアルゴリズムにはトレードオフがあって、 帯域を最大限に活用しようとすると収束が遅くなってしまい、 早く収束させようとするとあまり帯域が有効利用されなくなってしまう。 その具体的な論拠はこの論文で解説されている。 これはとくにわかりやすかった。なにより図が明快でいい。 もっと詳しい実装は、Stevens の教科書でも読んでくれってことで。
きのう Wavery Pl. でやってた市。
継承できる辞書を考える。
親がある場合は親のエントリを共有する。
class proptree(object):
def __init__(self, parent=None, **args):
self.__parent__ = parent
self.__dict__.update(args)
return
def __repr__(self):
return repr(self.__dict__)
def __getattr__(self, k):
if self.__parent__:
return getattr(self.__parent__, k)
raise AttributeError(k)
d1 = proptree(a=2, b=3)
d2 = proptree(d1, c=4)
print (d2.a, d2.b, d2.c) # (2,3,4)
昨日とはうって変わって、スカーーっと秋晴れている今日は (こんにちは)。
しかし寒くなってきたよな、それにしても。
新山はここにどうでもいいことばかりいつも書いているので、 たまにどうでもよくないことをすべり混ませても誰も気づかない (だろう、たぶん)。 つまり群衆の論理ってやつですよ。(何が? 何を?) とうぜん、そんなものはここに書かないがね。
さいきん発掘した写真:
計算機関連で 10年以上生きのびてる本ってのは、 それだけで「名著」と呼ばれるに値すると思う。 日本人が書いた本でそういうのってあるかなあ。 rootから/へのメッセージ なんかは、間違いなくそのひとつに含まれるだろう。
きょうは一日じゅうプログラムを作っていた。
プログラミングをしていると、いやなことを忘れられる。
ムカつく連中を一人ずつ変数に代入して、pickle してやるのだ!!
それってどういう意味?
ところで焼きギョウザにバルサミコ酢をかけて食うとあんまりうまくないことがわかった。
(なんだ、これは。こういうのはふつう「うまくいった」ものだけ書くべきなんじゃないのかっ。)
なにがまずいって、妙にあまいのだる。これはよくないね。
どうでもいいけどまた冗長化してきたのでこのへんで止
Document ID: af12fcb02dee500d6dfb258a5f9019d6
Yusuke Shinyama
