http://satoshi.blogs.com/life/2011/07/tepco2.html

政治家でも官僚でもない一国民が、自分の生の主張を理解されて、あるいは興味を持たれて自国の宰相と意見を交わせる。時代は進んだなと思わせる出来事である。ブログというメディアがあるからこそ実現した好例である。そして、管首相もなかなか思い切ったことをするな、と思った。

中島さんにはこれからも続けて意見を発信していって欲しい。そしてわれわれも傍観者ではいけないなと思う。自分だったらどうするかを一人一人が考えなければならない。傍観した結果が今のこのていたらくだ。頭上を飛び越された、政治や経済の専門家たちはおもしろくないようだが、専門家ほど信用ならない人たちが多いよね。自戒を込めて言うけど。

中島さんのプロフィールを読んでみると実は高校・大学の先輩だった…

六月は、イネの花粉症にかかってつらかった。どうも右の鼻だけつまっていて頭痛がするし、親知らずも痛いしで、耳鼻科に行ったら、アレルギー性鼻炎が原因だとのこと。私は花粉症だけど、いつもは三月に発症するので、風邪だと思っていた。どうやらイネの花粉にも反応するようになってしまったようだ。

MIYOSHIの無添加 泡で出てくるベビーせっけんはこの二つのポイントを押さえている。他のベビー石けんも二つ試したけど、一つはぬるぬるしないけど泡立ちがいまいちで（これは使い切った）、もう一つは流した後もぬるぬるしていた（こちらは早々に使うのをやめた）。

Zhi Wang and Huxian Jian

2010年のIEEE Symposium on Security and Privacyから。ハイパバイザそのものを保護するアプローチについて。著者のWangらはNorth Carolina State University所属。

本論文の投稿時点ではハイパバイザそのものは保護されていなかった。つまり、ゲストOSの制御を取ることが出来ればハイパバイザの制御も取ることが出来、悪用することが可能であった。本論文の提案が目指すのはハイパバイザの制御フローの完全性を保つことである。提案は二つの技術からなる。一つは、Non-Bypassable Memory Lockdownで、これはハイパバイザのメモリ領域をロックしてハイパバイザ以外の書き込みと実行を不可能にする技術である。もう一つは、Restricted Pointer Indexingで、ポインタの参照をテーブル経由の間接参照にすることで、ポインタの書き換えを防ぐ技術である。

Non-Bypassable Memory LockdownはIA32のWPビットを使っただけだし、Restricted Pointer Indexingは2010年以前に議論されていたような気がするので、アイディア自体は進歩しているようには思えない。LLVMを改造して制御フロー分析の部分を実装したりして、実装は結構大変だったろうなと思う。

おもしろかったのはType-IIハイパバイザでHyperSafeの技術を使う際の課題を議論しているところだ。HyperSafeはType-Iハイパバイザの構成を前提に設計と実装がされている。そのため、その技術をType-IIハイパバイザの構成に持って行くときにはいくつか問題があると言っている。一つは、Linuxのような現代のOSは性能至上主義でそのためにダブルマッピングや混合ページが多用されており、これがNon-Bypassable Memory Lockdownを難しくすることである。もう一つはクローズドなローダブルモジュールで、このようなモジュールはソースコード解析が出来ないので、ごく簡単に言うとRestricted Pointer Indexingを適用できない、ということである。

いささか旧聞だが、アップルのMagic Mouseはなかなかよい。Mighty Mouseはポッチをぐりぐりしているうちに汚れてきてしまってききが悪くなってしまうのだが、Magic Mouseならそれは起こらない。びっくりしたのはあの中に単三電池が二本入るということだ。はじめあまりに薄いので専用の充電池でも使っているのかと、思わず店員に聞いてしまった程だ。

こんなMagic Mouseだが、いまのところ私のMighty Mouseは割と快適に使えているので買うまでには至らなかった。

このブログの記事を読んで改めて議事録の大切さを感じ、最近の会議では議事録を書くようにしている。ここで問題になるのは、タイピング速度である。議事録を書いてみればすぐに分かることだが、人の話すスピードには波があって、遅いところでは余裕で発言を記録できるが、速いところではタイプが追いつかないことが多い。とてもじゃないが、会議中に漢字変換なんてやってられない。

そこでとうじょうするのがかなぶんである。ようはかかまぶんだからよけいなおーばーへっどがかかるわけで、かなぶんならきいたおとをそのままもじにするだけなのでタイプをはやくすることができる。とりあえずかかまぶんできろくしておいて、あとでまとめるときにかんじなりなんなりにへんかんすればよい。でもなれないうちはついすぺーすばーをうってかんじへんかんしてしまったりしてそれがオーバーヘッドになったりしてしまう。わ）

ちなみにこのアルゴリズムは弱いのでほとんど点が取れません。

ダウンロード

「自分で考えて答えを出すのと、他人から聞いた答えが正しいかどうかを確かめるのとでは、どちらが簡単か」

推理小説は好きで、特に東野圭吾の小説は好きでよく読む。論理にあらがないし、かといって論理がむき出しにならず、娯楽として楽しめるところがいい。台詞が自然なのもいい。この小説の内容は、数学者が企てた完全犯罪を主人公が暴くというもので、結末が衝撃的で非常におもしろい。

冒頭の台詞は物語の終盤で容疑者の数学者が主人公に対して言う台詞で、これがこの小説のテーマである。この問題はなにも数学や犯罪の世界に限ったことではなく、われわれの日常生活でも常に問い続けなければならない問題である。しかし、現実の世界はすべてを自分で考えて答えを出すには複雑すぎる。これに対して、今の世の中は便利で、様々な事柄に対して既に解答が用意されていることが多い。特にウェブの功績によるところは大きい。しかし、その解答が正しいかを自分なりに証明するには、それなりの労力を必要とする。解答を鵜呑みにするという方針は方針として認めるが、果たしてそれで自分の人生を生きているという実感は得られるのだろうか。

冒頭の台詞はあるいは仕事をする人にとっての大原則でもある。複雑で巨大なものは多くの人の分業によって成り立っている。冒頭の台詞は、個々の仕事を統括する立場にある人への直接の問題提起でもあるし、個々の仕事している人への結果の出し方のアドバイスでもある。

基調講演ではHTML5で記述された水槽アプリがぐりぐり動いていたのが印象的でした。IEでは250匹魚を泳がせると3FPS程度に落ちるけど、Chromeでは20FPS も出るよというデモンストレーションでした。HTML5は機能としてはブラウザに乗るようになったので、これからは実用化のフェーズ、つまり、GPUを積極的に活用して性能を上げていくフェーズになる、という話でした。HTML5に関しては全く知識がないのですが、これだけ色々動くならちょっと手を出してみたいなと思いました。

あとは日本語入力をプッシュしていました。冊子を配る程のアピールで、それを読んでみると確かに今までの日本語変換とは違うなと思いました。しかし、開発途中だからでしょうか、デモでは一部失敗もしていました。日本語入力使ってみたいと思いましたが、個人的にはどのようにそれを開発したのかというメーキングストーリーに興味を持ちました。20％ルールはこういう風に使われているのか、と納得しました。

Androidの話題は、最新情報とか将来のロードマップのような話はなく、様々なアプリの分野での開発経験が中心でした。各トークに共通していたのは、いかに性能を出すかという話題でした。スマートフォンのリソース制約は依然として問題のようです。

全体的に見て、AndroidアプリとかWebアプリとか楽しそうだな、と感じました。ユーザーのフィードバックを直接得られるのは長所ですね。是非チャレンジしたいですが、DoCoMoには魅力的なAndroid端末がないのが非常に残念です。

自然現象の作り出すさまざまな模様や造形をカメラに納める。そうして撮られた写真が20点あまり、その撮影方法と共に紹介されている。自然現象とは言っても、効率よく撮影するために人為的に現象を作る必要があり、その方法を惜しげもなく披露しているところが、この本のもう一つの魅力だ。

撮られた写真は、風景や人物とは全く異なるものの、その綺麗な模様はどれも鑑賞に値する。とはいうものの、写真はあくまで結果であって、私個人はむしろどうやって撮ったかという方に興味を引かれた。