ジュリエット... ― 2007/05/31 19:38
iMac G5 熱対策 ― 2007/05/04 22:04
我が家のメインマシンはiMac G5 (iSight)だが，長らくメモリを512メガバイトのままでなんとかやりくりしてきた。さすがに夫婦二人がファスト・ユーザー・スイッチをしながら使うには512メガだと辛く，ユーザーを切り替えるたびに一分から酷いときには二分も待たされることがしばしば。ページアウトどころか完全にスワップ落ちしているようである。まぁ，OLYMPUS Studio※1とiPhotoとiTunesとMailとSafariが同時に起動していて，さらに嫁がSafariのタブを十以上も開くので無理もない。
どうせ飲み会に誘われればCPU課金で一万円搾り取られるなら※2，家族のために後に残る出費も悪くはないと思い立ち，先週秋葉原で1ギガバイトの追加メモリを購入した。併せて1.5ギガバイトの環境にしたらメモリを使いきることなく，サクサク動くようになった。もう，快適の一言に尽きる。こんなに速かったのか，iMac G5。メモリが潤沢にあれば，の話だが。昔のOSは数百キロバイトの制限の中で動いていたもんだけれどねぇ...
ところが最近，頻繁にCPUの温度が高くなり，iMacが自動的にスリープするようになってしまった。CPUに負荷のかかる処理をするとすぐにスリープに入ってしまう。OLYMPUS StudioでRAWデータからJPEGへの変換をバッチ処理で九十枚ほどやらせるとダメ。MediaFork※3でDVDをH.264のmain profileに変換させてもダメ。とにかくCPUに仕事をさせると，五分と持たない。システム環境設定でプロセッサのパフォーマンスを『自動』から『低』に落としても，スリープに入るまでの時間が稼げるだけで，結局はスリープしてしまう。
CPUの温度がどんなになっているのかと思い，iStat Nano※4でチェックすると，定常状態でCPUの温度は七十度を超えている。CPUにちょっと仕事をさせるとすぐに温度が八十度ちかくまで急上昇し，そしてスリープ。iMac G5の初期型で放熱処理に問題を抱えていて，基盤の設計からやり直したはずのiMac G5(iSight)でこれでは，いかんともしがたいのである。
とにかく熱対策をせねば，とネットでいろいろ情報を探っていたら，今まで気がついていなかったところに吸気口があることを発見 - いや，発見と言っても，ちゃんとみてれば普通に気がつくだろ，というところにあったのだが - 本体を支える支柱の陰に，大きめの吸気口があるではないか。試しにここを指で拭ってみると，案の定ほこりまみれ。ということで，ウェットティッシュとブラシで掃除してやると，掃除している最中から急にファンの音が大きくなり - つまりそれまではファンの音さえ消してしまうほど吸気口が詰まっていたわけだが - CPUの温度が一気に下がった。
以来，CPUは定常で六十度前後，重い処理をさせても六十度台で推移するようになった。当然，ファンの回転数も3600rpmから1100rpmまで落ち，静かに稼働するようになった。
今回の教訓。吸気口の掃除は大切である。吸気口がどこにあるのかを知っておくことは，もっと大切である。
※1: OLYMPUS Studio
オリンパスのカメラが記録するRAWファイルをJPEGに変換するために使用している。使い勝手はもちろんPhoto Shopなどのほうが良いが，OLYMPUS Studioで現像しないといわゆる『オリンパス・ブルー』が再現できないという神話があり，いまもこれを使っている。神話の真偽については定かではない。
オリンパスの製品ページ
※2: CPU課金
マネージャー以上の人間であれば，本人の可処分所得に関係なく，一律高い飲み代を幹事が要求する習慣が僕の勤める会社にはある。CPU課金と呼ばれているが，人頭税と言ったほうが正確だろう。
※3: MediaFork
ちょっと前まではHandBrakeという名前のソフトだった。一昔前，MacでDVDをリッピングするには，ffmpegやらなにやら面倒くさいツールを使わなければならないことが多く，また映像と音声は別々に処理をしなければならず，そしてその面倒な作業をやったのに映像と音声がずれるということもしばしばで，とても僕のような素人に手を出せるものではなかった。そこにOpenShiivaという『お手軽一発変換ソフト』が出てきて随分ありがたい思いをした。やがてHandBrakeが出てきて，H.264などに対応していることもあってこれに飛びついたのだが，先日最新版をダウンロードしてみれば，MediaForkという名前に変わっていた。ただ，まだサイトのURLもタイトルもHandBrakeのままだ。
HandBrake
※4: iStat Nano
Mac OS X 10.4の便利な機能のDashboard。そのDashboardのウィジェット(アプリケーション)として動作する，CPUやメモリやその他もろもろのハードウェアの稼働状況を報告してくれるツール。ちなみにDashboardが便利だからといって，ウィジェットをあれこれ貼付けておくと結構なメモリを喰う。
iStat Nano
Outlook 2007、いまだ成熟せず ― 2007/04/24 14:26
ここのところ、会社でずっと Outlook のヘルプデスクのようなことをしている。「あの Outlook 嫌いが?」と思う人もいるかもしれないが、サラリーマンなんてのはそんなもので... まぁ、現実には、チームのメンバーが精力的にヘルプデスク作業をこなしてくれるおかげで、僕のところに回ってくるのは文字化け系の解析作業ぐらいだけれど。
ところで、ヘルプデスクの中でみかけた「いまだにそんなっ？」なできごとをひとつ。
X-Mailer: Microsoft Office Outlook 12.0 を名乗るクライアント - おそらくは Outlook 2007 - から送られてくるメールの件名が文字化けする、と報告を受けた。調べてみると Outlook 12.0 とやらは、Subject 行に ISO-2022-JP の文字列をそのまま使っている。B-Encode していない。つまり、一昔前によくみた「Subject の生JIS問題」がふたたび起こっている。
いまだにそんなことするのか。
RFC2822 形式のメールでは、Subject 行は unstructured filed と定義されており、unstructured field に使えるのは US-ASCII (の CR/LF を除く部分)だと明記してある。
2.2. Header Fields
Header fields are lines composed of a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF. A field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon. A field body may be composed of any US-ASCII characters, except for CR and LF. However, a field body may contain CRLF when used in header "folding" and "unfolding" as described in section 2.2.3. All field bodies MUST conform to the syntax described in sections 3 and 4 of this standard.
2.2.1. Unstructured Header Field Bodies
Some field bodies in this standard are defined simply as "unstructured" (which is specified below as any US-ASCII characters, except for CR and LF) with no further restrictions. These are referred to as unstructured field bodies. Semantically, unstructured field bodies are simply to be treated as a single line of characters with no further processing (except for header "folding" and "unfolding" as described in section 2.2.3).
で、US-ASCII との互換性を意識して設計された(※1) ISO-2022-JP には、RFC2822と衝突するようなシークエンスはない。昔はRFC2822 の Unftructured Field の body に許されるのは US-ASCII の printable部分で、そうなると ISO-2022-JP で使われる ESC (0x1B)が実は衝突する、だとか、そもそも US-ASCII の printable とはなにか、そこに ESC は含まれるのか含まれないのか、という論議がずっとあった。これに決着が付いた、という話は聞いたことがない。たんに勉強不足なんだろうけれど、あれはなんだったんだろう。いまRFC2822を斜め読みするぶんには、ヘッダーの名前は US-ASCII の、コロン(:)を除く printable 部分しか許されない、ヘッダーのボディは US-ASCII の CR / LF を除く部分を使っていいよ、CR / LF はヘッダーを折り返す(header folding)ときに使ってね、と書いてあるだけのように読める。
つまるところ、Subject に許されるシンタックスだけに注目するなら、実は ISO-2022-JP をそのまま使うのは是か否かというと、これはどうも「是」であるような気がする。
いずれにせよ、よしんば Subject 行のシンタックスとしてISO-2022-JP が許されるとしても、「これは ISO-2022-JP のシークエンスとして扱ってほしい」というセマンティクスはそこにはない。US-ASCII の文字が羅列されているだけで、その文字列をどの文字符号化方式として解釈してやらなければならないのか、その情報はどこからも与えられない。ISO-2022-JP のようにも解釈できるシークエンスを書いた人が、それを ISO-2022-JP として解釈してほしいのか、それとも US-ASCII として解釈してほしいのか、それは Subject 行そのものからはうかがい知ることはできない。そして、上に挙げたRFC2822の引用部分には重要な記述がある。もう一度みてみよう。重要なのは太字で下線がついている一文だ。
2.2.1. Unstructured Header Field Bodies
Some field bodies in this standard are defined simply as "unstructured" (which is specified below as any US-ASCII characters, except for CR and LF) with no further restrictions. These are referred to as unstructured field bodies. Semantically, unstructured field bodies are simply to be treated as a single line of characters with no further processing (except for header "folding" and "unfolding" as described in section 2.2.3).
セマンティクスとしては、unstructured field のボディ部分は、単純なキャラクターの連続として扱い、それ以上の処理を施すべきではない、と書かれている。つまり、それが ISO-2022-JP のシークエンスのように見えても、それは US-ASCII として扱うべきだ、(RFC2047 の形式で無い限り)、プロアクティブに「何か別のコード体系」として処理してはならない。
いい加減、Microsoft も実践的な解法に従うべきではないのか。つまり、Subject にRFC2047で定義されたセマンティクスを与えてやればよい。たんに ISO-2022-JP を B-Encoding するだけで達成できる。そして、日本語対応を謳うメールクライアントなら、Subject 行の B-Encoding された ISO-2022-JP なら間違いなくデコードできる(※2)。
僕の手元に Outlook 12 (Outlook 2007?)があるわけではないので、送信者がどのような設定をしているのかはわからない。だが、どのような設定であれ、ISO-2022-JP をベアで(つまり生 JISで) Subject に突っ込むべきではないと思う。そのぐらい、もう Outlook を日本市場に投入して長いのだから、いい加減改めろよな、と思う。
※1
まわりくどい言いかたをしているけれど、つまりは 7bit ということ。
※2
もちろん、B-Encoding がまっとうに行われていれば、の話。外国産のメールクライアントには、いまだに B-Encoding を RFC に書かれたとおりに行わないものがある。行のフォールディングに CR + LF を使わずどちらかだけになっているとか、一行が 75文字を越えているとか、US-ASCII 部分と encoded-word 部分が一文字以上の空白文字で区切られていない、とか...
そもそも、B-Encoding などという「しちめんどうくさいこと」をしなければ日本語の情報が交換できないということ自体、現行の規格には無理がある。そろそろ、7bit ではないと通信路上でのデータの安全が確保できないなどという前世紀のくびきから解き放たれて良いころだろう。8bit 転送を前提に、よりシンプルなマルチバイト文字の交換が本当の意味で可能になるのはいつの日のことか...
POP3をいつまで使うのか ― 2007/04/20 01:20
IPAが APOP（エーポップ）方式におけるセキュリティ上の弱点（脆弱性）の注意喚起について勧告を出している。APOPのチャレンジ・レスポンスに利用されるMD5ハッシュに脆弱性があり，サーバーに成り済ました悪意ある第三者にパスワードを盗まれる可能性がある，というものだ。IPAではPOP over SSLやウェブメールなどへの移行を勧めている。
いうまでもないが，POP3は古いプロトコルである。もともとのPOP3の規格では，パスワードは平文でネットワーク上を流れていた。そんなことをしても問題にならないほど平和な時代に作られたプロトコルであるとも言える(※1)。のちにパスワードを平文で流すなんてことが許されなくなるとRPOPやAPOPが考案され，結局APOPが主流になったのだけれど，そもそもいつまでPOP3を使うのか。
Solaris 2.6のころだと思うが，SunがIMAPサーバー機能をOSに同梱したことがある(※2)。あのころ，「なぜにIMAP?」というのが僕の疑問だった。せっかくのIMAPサーバー機能だが，まだクライアントがIMAPを十分に実装できていなかった。なにせWinbiffやAlmailが圧倒的なシェアを持っていた頃である。サーバーだけがIMAPを実装していても，まったく使えなかった。結局，qpopperを導入してお客さんに納めていた。
今思えば，Sunの選択はあながち悪いものではなかったと思う。当時，すでに複数のクライアントからメールを読みたいという要求が強くなりつつあり，そのためにはIMAPのほうが適していた。IMAPは最初からメールをサーバー側で保管するように設計されていたからだ。IMAPではクライアントはローカルにメールのコピーを持つ必要はなく，複数のクライアントからメールにアクセスするという用途にはうってつけだった。POP3もUIDLという苦し紛れの - それでも特定の用途には十分に機能した - 解決策を見いだしたが，いかんせん，サーバー側でメールをフォルダに振り分けて管理することができないのが致命的だった。POP3のUIDLは，単にサーバー側に保存されているメールの，一度も読まれたことのないコピーがどこからかを示す機能しかなかった。またPOP3は，サーバー側に保存されているメールを条件検索する機能も備えていなかった。メールを使い始めて数ヶ月もすればサーバーに相当数のメールが溜まる。効率よくメールを検索するための方法がなければ，ユーザーは結局はローカルドライブにメールを保存するしかない(※3)。
IMAPは完全ではない。それでもPOP3よりは使い勝手が良い。自宅のPCがVPNで会社のLANに乗り入れることができるなら，あるいは，会社のIMAPサーバーがDMZ上でサービスを提供しているなら，わざわざ会社のPCを自宅まで持ち運ばなくても自宅でも職場と同様にメールにアクセスできる。サーバー側にフォルダ・ツリーがあるから，POP3のときのように職場と自宅ではメールを振り分けたフォルダが違っていて困るなんてことはない。サーバーに保存されているメールを効率よく探し出すための条件検索も，IMAPではプロトコルに組み込まれている(※4)。
いずれにせよ，IMAPがこれほど広く受け入れられている状況で，POP3を使う必要があるのか？インターネット・プロバイダーのように巨大なユーザー・ベースを持つところは，IMAPにするとユーザーのクォータという問題に突き当たるのでPOP3がいまだにありがたいのかもしれない。が，しかし，Apple は .MacではPOP3ではなくIMAPでサービスを提供しているし，クォータの話をするならば，Google mailやYahoo! Mailはすでにギガバイト単位の容量をユーザーに与えている。
APOPに脆弱性が見つかったからどうというのではないが，そろそろPOP3を「終わらせ」てもいいんじゃないだろうか。
註:
※1
パスワードの保護とは観点が違うけれど，同じくらい古いSMTP/ESMTPのほうはいまだに認証なしで接続を受け付けるのが多い。企業内だとまずSMTP-AUTHにしていないのではないか。
※2
僕はSolaris 2.6までしか触っていないので，今のSolarisでもIMAPサーバー機能が同梱されているのかは知らない。
※3
現実には，IMAPのユーザーも検索や表示のパフォーマンスの問題から，ローカルコピーを多用している。
※4
もっとも，検索のパフォーマンスについては，サーバーのアルゴリズムと処理能力に大きく依存する。メールボディへの全文検索を行わないように設定できるサーバーがあるのも，条件検索がIMAPサーバーにとっては決して軽くはない操作であることを物語っている。結局，ユーザーは利便性を損ねているのかもしれない。
IdM for SMBs ― 2007/04/19 13:36
Oracle は社員によるオフィシャルなブログサイトを持っているが、(英語のみ)、IdM 関連で面白いエントリがあった。 IdM is different for SMBs と題されたエントリ。Nishant Kaushik が書いている。
以下、勝手な意訳。許可を取っているわけではないので、怒られたら消します...
中小企業マーケットでは IdM が違う
カスタマー・アドバイザリ・ボード(CAB)(※1)では興味深い論議をいくつかしたが、そのひとつに「アイデンティティ管理に関してどれほど大企業と中小企業で意識に差があるか」というのがあった。Thor Technology は起業に際して、大多数の企業のニーズを満たすのではなく、特定のマーケットに集中しなけれ ばならなかった。そして、私たち(Thor)は金融業界で力を蓄え、今日に至っている。金融業界では、Thor の強みを活かせる顧客をもっぱら相手にした。とても洗練された要件を持ち、柔軟に拡張できる製品を必要とし、(とくに創業期のThor にとっては重要な要素である) 巨額の予算をもつ顧客たちである。やがて時が経ち、私たちは他のマーケットへの扉を開けつつあることに気がつき、そして同業者がすでに知っていたことを悟るにいたった。つまり、中小企業マーケットは、とても難しい「猛獣」なのである。
中小企業マーケットでは、キーワードは「箱から出してすぐ」(※2)である。システムは、追加の作業なんかほとんどせずに、すぐに使えなければならない。
以前の顧客たちとは正反対である。私たちがそれまでにアイデンティティ管理として理解していたもの - 業務処理と承認ワークフローは企業ごとに独自で、企業のインフラストラクチャは高度に作りこまれており、そしてユーザー・コミュニティは多種多様 - と「箱から出してすぐ」の概念はまったく相容れなかった。中小企業マーケットに踏み込むために私たちが取り組まなければならないふたつのこと - 「標準で提供されるもの」と「使い勝手」に気が付くまで、すこしばかり時間がかかった。
「標準で提供されるもの」が本質的に意味することは、私たちが製品として提供するものは何であれ、(それがコネクタだろうとワークフローだろうとポリシーだろうと)、一般的な使用用途に対応していなければならない、ということだ。
もし作りこみが必要なのであれば、その作業を無理なく簡単にするための使いやすいツールが必須となる。製品として何が提供されるべきかについてのカスタマー・アドバイザリ・ボードでの論議は、激しい討論となった。大企業の顧客はもっとたくさんの機能と柔軟性を製品に求めている。私たちが何を製品に含めるにせよ、彼らの独自の環境に適合するためには多くの作りこみを必要とするのだから、彼らは製品に標準で添付されてくるものに注意を払わない。一方で中小規模の顧客は製品として何が提供されるのかについて注意を払い、そして製品を拡張し操作するツールについても気にしている。私たちはどのようにしたら、ユーザビリティを損なわずに高い柔軟性を維持できるだろうか？このバランスをとることは、とても興味深い活動ではある。
その答えは、機能を多層的に抽象化するモデル - 低次の抽象化レイヤーの上に高次の抽象化レイヤーを持つモデル - を構築することにある。最大限の柔軟性が必要な顧客は、低次の機能抽象化レイヤーに取り組めばよい。設定・構成作業を最低限に抑えたい顧客は、高次の機能抽象化レイヤーだけを気にすればよい。これは OIM が最近実装したエレガントなソリューションだ。今後、私たちはこの機能を単に拡張するのではなく、この考え方を IdM 製品ラインの全体へ押し広げていく。中小企業マーケットは現在オラクルが本気で取り組んでいるビジネスであるから、これは、オラクルにとってきわめて重要なことである。
事実、Oracle Identity Management は中小企業マーケット向けの専用ページを開設している。そこには価値のある情報があるので、チェックしてほしい。
中小企業マーケットで IdM に対して何が本当に必要とされているのかを、コミュニティから聞くことは役に立つであろう。これまで述べてきたように、IdM 製品は、伝統的に中小企業マーケットの要件をぜんぜん満たしていなかった。しかし現在、この状況は変わりつつある。Oracle も、Novell や Sun などの他のベンダーも、中小企業マーケットに対応するために製品ロードマップに重要な変更をおこなっている。しかし、まだまだ取り組まなければならないことは多い。なぜなら、実装費用に対するライセンス費用の比率は、いまだに実装費用のほうがはるかに大きいからだ - ライセンス費用が安いからというのが理由ではなく、実装費用が嵩むというのが理由だが -。
P.S.
これを書くために Oracle IdM for SMBs のページを参照したら、中小企業顧客向けに特別価格キャンペーンを実施していることに気がついた。このキャンペーンは期間限定のようだが、ぜひ見てほしい。そのページで中小企業での実装事例として、Silicon Image の成功事例を読むことができる。
註:
※1
CAB... Customer Advisory Board。顧客から製品のフィードバックを得るために定期的に開催される Oracle と顧客グループとの会合。
※2
原文は Out-Of-The-Box。インストールすれば面倒な設定やチューニングやカスタマイズなしに業務用に動作することを言う。
ひとつの Terminal セッションを共有する ― 2007/03/09 17:37
昔はこういう「技」は師匠から弟子へ伝えられたものだが...
書いときます。
Terminal でやっている作業をみんなで見守る方法。
Terminal A から。$ telnet localhost | tee /tmp/akioTerminal B から。もちろん、別マシンからの SSH/Telnet でよし。
$ tail -f /tmp/akio
Terminal A (作業する人)があえてローカルマシンへ telnet し、標準出力を tee で分岐するところがミソ。
昔は Web Conferencing なんて要らなかった。テキストが世界のすべてだったころはよかったなぁ...
NTEmacs: ispell その 3 ― 2007/03/02 17:09
; Cygwin では egrep が grep へのシンボリックリンク (setq ispell-grep-command "grep")あと、ispell-complete-word を使うなら、/usr/dict というディレクトリを掘って、wordsファイルのアーカイブを置いてくれている人の親切にすがりながら、ダウンロードした words ファイルを /usr/dict/words に配置すること。
NTEmacs: ispell その 2 ― 2007/03/02 14:45
;;
;; ispell
;;
(autoload 'ispell-word "ispell" "Check the spelling of word in buffer." t)
(autoload 'ispell-region "ispell" "Check the spelling of region." t)
(autoload 'ispell-buffer "ispell" "Check the spelling of buffer." t)
(autoload 'ispell-complete-word
"ispell" "Look up current word in dictionary and try to complete it." t)
(autoload 'ispell-change-dictionary "ispell" "Change ispell dictionary." t)
(autoload 'ispell-message "ispell" "Check spelling of mail message or newsx post.")
(defun ispell-tex-buffer-p ()
(memq major-mode '(plain-tex-mode latex-mode slitex-mode yatex-mode)))
(setq ispell-enable-tex-parser t)
;; 日本語部分をスキップする
(eval-after-load "ispell"
'(add-to-list 'ispell-skip-region-alist '("[^\000-\377]+")))
最近の cygwin は ispell ではなく aspell が入っているようなので、次のようにしておく。
(setq-default ispell-program-name "aspell")
NTEmacs: ispell ― 2007/02/27 11:25
Mew でメールを書くとき、英語のスペルチェックには ispell を利用している。NTEmacs の環境から ispell を使うには、cygwin で aspell.exe を導入する。
cygwin では、Text カテゴリに aspell が収録されている。aspell.exe をインストールしたら、Emacs / Mew 側での余分な作業は必要なく、そのまま ispell が使える。 NTEmacs 側での作業は必要。以後の記事に説明を書く。
NTEmacs: w3m ― 2007/02/27 09:54
Mew で HTML のメールを読むためには、w3m と emacs-w3m が必要。
w3m を Windows 環境に導入する最も簡単な方法は、cygwin。cygwin のインストール時に(インストール後でもいいけど) w3m を選択してインストールし、%cygwin_path%\bin を PATH 環境変数にいれておけば、それでいっちょあがり。
emacs-w3m はソースを落としてきてコンパイルする。cygwin で gcc や make を入れておく必要がある。コンパイル自身は ./configure -> make -> make install で Emacs の share\sitelisp へ放り込んでくれるので、簡単。らくちん。
最近のコメント