Exynos騒動に関連して一言

Exynos 4210と4412の設計ミスか？　と、ちょっとワクテカしたのだがいまひとつ残念だったというのが率直なところ。

とはいえ世の中に出ているAndroid機器の台数では相当なものだろうから、CPU依存コードの修正版が配布されるまでは利用者にしてみればドキドキもんだろう。

今回の騒動は要するに、Androidの下にいるLinuxのCPU依存コード（カーネルコードの共有ライブラリ）をミスってユーザランドからカーネルメモリも自由に読み書きできるようになってました、という間抜けな話。Linuxカーネルのなかみはよくわからないけれども、メモリセグメントのrwx権限をもつテーブルかなにかのフラグ管理を間違えたんだろう。この手のミスは、複数箇所でフラグをいじるようなコードを書くと生じやすいので、ぶっちゃけスキル不十分なプログラマを投入した上に、きちんとしたコードレビューができるチームでなかったというところではないだろうか。

仕事上、韓国のIT技術者や研究者と接する機会が多いのだけれども、こういうところの品質が担保できる人材は少ないんだろうなと思うことが多い。日本メーカーもソフトウェア開発は苦手だけれども、そしてそれが組織作りや運営の問題ということが多いのだけれども、韓国人は日本人より大陸的というか、現場で失敗しながらスキルを身に着けることをよしとする傾向が強いので、上司（儒教社会なので目上や上の立場の人は絶対）が無能だとろくでもないものがあっさりと世の中に出てしまう感じだったりする。

で、一部にはAppleのiOSデバイス用CPUもサムソンの設計だからと怖がっている人が一部にいるみたいだけれど、AppleのAシリーズ開発はカリフォルニアでがっちり管理しているし、あのうるさいジョブズがこういう基幹技術の流出をよしとしたはずがないので、関わるエンジニアは完全に隔離されているというAppleとサムソン両者の説明はあながち嘘ではないと思う。

とはいえ、A4にはLimera1n exploit、A5にはデュアルコアの間の一貫性管理のミスというCPUロジックの致命的欠陥が脱獄に利用されているので、AppleのCPUだから安心というのはあまりに楽観的にすぎるといえる。iOSデバイスの場合、脱獄への強い動機があるので妙にトガッたティーンエージャーやそれ上がりの大人が寝食惜しんで脆弱性探しをしていることで発見されやすいのだけれど、おそらくどのメーカーのCPUにもexploitにまで組み上げられる何らかの欠陥のひとつやふたつは抱えているのだろうと思う。

知人の論理検証専門家が自社のCPUを対象に自分の研究成果を適用したらぼろぼろエラーが見つかって、上司に報告したらその検証ツールはお蔵入りにされたという話もきいているから、納期やコストなどの都合で、仕様書通りの動きさえすれば品質管理部門はOKを出しているのが実際のところではないかと思う。

つまるところ、ITに限らず製品やサービスに絶対の安心はないということ。人がやることなので、想定外とか手抜かりを見逃すとかいうことは必ずあるということを前提に付き合わざるをえない。「面白いなー」「便利だなー」で無邪気にアプリ収集に邁進したり、どっかの紹介やランキング上位を真に受けて突進するのは危ういと心がけるべきだ。

特に、なにかの記事や本での紹介は実質広告に過ぎないケースは多いし、ランキングというのは噂を流したり人海戦術でダウンロードしたりすることで簡単に上位に上がってくるものだ。ランキング操作も広い意味では「ステマ」の一種といえるだろう。詐欺の片棒担いだ「ステマ」有名人をあげつらう前に、「それは本当に必要なのか」と自分に問う習慣をつけるほうが、人生のいろいろな場面で余計なトラブルを避ける上でも役に立つはずだと言っておきたい。

iOSの行動追跡回避設定について

結構あちこちで語られているので常識ではないかと思っていたのだが、意外と知られていないようなので、念の為に書いておきます。

iOS 6以後、広告配信のための行動追跡機能がデフォルトでオンとなっています。Appleは以前CarrierID問題など、利用者へのわかりやすい説明をしない形での様々な行動追跡問題を起こしてきましたが、今回もそれの繰り返しです。

GoogleやFacebookが様々な形でデバイスやサイトの利用をデータとして集積し、分析して、建前上は「サービス向上のため」となってはいますが直接的には商売（広告屋に売るなど）に使っていることが批判されますが、Appleも同類です。

まず、「設定」アプリを起動します。

「設定」アプリを起動

「一般」を選択します。

「一般」を選択

次からが、何らかの意図を感じるところなわけですが、Appleらしいといえばそのとおりというしかないわけですが、設定変更項目が、「情報」のところにあります。

なぜか設定は「情報」のなかにある

画面をスクロールしていちばん下から3番目に、「アドバタイズ」という不自然な日本語があります。これを選択します。

いちばん下までスクロールしていくと、ようやく「アドバタイズ」の項目が

すると、またもや不思議な日本語「追跡型広告を制限」があります。

なんだか、制限すると悪いことが起きるような印象を受けますが、追跡されたくない人は制限する設定をすべきなので、これを「オン」に切り替えます。

なんとなく抵抗を感じさせる不思議な説明だがかまわず「オン」に

これで行動追跡停止が設定される

ついでなので、その下にある「Advertising Identifire（広告識別子）をリセット」も押しておきましょうか。たぶん、以前追跡されていたときと別のIDが生成されるのだと思います。

ついでなので、追跡用IDも作りなおしておく

設定はこれだけですが、まだ罠があります。例えば、OSのアップデートなど、何らかの設定を引き継がなければならないような変更を加えるときに、この設定は再び、「オフ」に戻ります。（ただし、今回iOS 6.1 beta2からbeta3へのOTAでは解除されなかった）

もしかすると、他にもiTunesと同期する時とかに外れたりするかもしれませんので油断はできません。再起動したときも怪しいかもしれません。とにかく、隙があればこの設定はすぐに「オフ」になるので、たびたび確認して、「オン」が維持される条件を確定するまで安心できませんが、将来的にその条件が維持されるかどうかも保障できないので、何事かあったときにはすぐにここの設定に戻るようにするのが賢明ではないかと思います。

Saurikが集めている情報

Cydiaには、「Manage Account」という機能があり、Cydia経由で購入した有料アプリやTweak等を、あとからGoogleアカウントもしくはFacebookアカウントを使ってCydiaにログインすることでいつでも「購入済み」としてダウンロード&インストールできるようになっている。

この機能はとても便利だ。同じアカウントからならば、複数のiOSデバイスに、どのバージョンのiOSからでも同じ有料アプリやTweaksを追加の費用なく入れることができるからだ。

もちろんこれは、AppleのApp StoreやGoogle Play、Microsoft Storeなどとも同じで、それぞれのアカウントにアプリがひもづけられ、ひとつ購入すれば同じアカウントで使う限りどのマシンやデバイスにもインストールできる。Cydiaがこれらと違うのは、Apple, Google, Microsoftがそれぞれにアカウントを作らせて、それぞれが独自にアカウント情報とアプリ情報を管理しているけれども、CydiaはGoogleアカウントやFacebookアカウントでログインするので、Cydia用のアカウントは不要ということだ。

少しネットの事情に詳しい人なら、他にもWebサイトで独自のアカウントを作らせずにGoogleやTwitter、Facebookのアカウントなどでログインできるように作っているところが結構あることをご存知だろう。そして、Open IDやOAuthなどといったしくみについてもご存知の識者もおられることだろう。

ここから類推するならば、CydiaのバックエンドであるAmazon AWSサービス側にはアカウント管理のしくみはなく、いわゆる（広い意味での）Open IDで利用者管理を行っていると考えるところだろう。つまり、Cydiaは利用者識別情報とそれに関する購入情報の対応を持っているだけで、それ以外の情報は一切持っていないはずだと。

ところが、あるときGoogleアカウントのダッシュボードで、関連付けられているアプリ及びアクセスされる情報を確かめる必要があったとき（2要素認証を設定すれば必ず目にすることになる）、Cydiaが3つのアクセスをかけていることを知ってしまった。ひとつは、個人のプロフィールなどアカウントへのフルアクセス、次に連絡帳、そしてGMailだ。ここに魚拓を貼ろうと思ってダッシュボードを開いてみたが、いったん2要素認証を外して再設定したのち、一度もCydiaを使っていないため、すべてがクリアされており、魚拓がとれなかった。もしこれを読まれた方で、心当たりのある方は、ご自身のダッシュボードを確かめてみていただきたい。「Googleアカウントに許可された項目」、英語なら「Websites authorized to access the account」となる。

Facebookの場合、僕はFacebookには詳しいプロフィールを入れているため警戒してCydiaには使っていないので、どのようになるかはわからないけれども、おそらく同程度の内容にアクセスしている可能性がなくはない。心当たりがおありの方は、FacebookサイトでCydiaが何にアクセスしているか確かめてみていただきたい。

Saurikが集めた情報を何に使っているのかはわからない。また、それを示唆する調査が行われたという話もきいたことがない。けれども、瞬間風速で世界中から同時に莫大なアクセスがかかってもびくともしないCydiaのことだから、おそらくAmazon EC2で無制限にスケールアウトするような契約になっていても不思議ではない。そして、そのために支払っている費用は膨大な金額だろう。CydiaはWebアクセスするほぼすべてのページに広告が入っているけれども、果たしてその広告収入だけでどこまで費用を賄うことができるのか、あるいはそれ以外の資金が投入されているのか、もちろん誰にもわからない。

もうひとつ、Cydiaで購入したアプリやTweaks等はすべてSaurik名義での請求になる。たとえそれが$0.99のものであっても、数$のものであっても、いったんSaurikの口座を経由して作者に支払いがなされているのは間違いない。実際にファイルが置かれているリポジトリは外部にあることが多いけれども、それでもPayPalからの請求書には必ずSaurikIT, LCCと書かれている。これまで疑問には思わなかったけれども、Cydiaで「購入済み」と表示できるようにするためにはCydiaのバックエンドで購入行為を管理するというのはわかるものの、Saurik名義ですべて請求する必要が絶対にあるかどうかには議論の余地があるように思われなくもない。

Cydiaはapt-getをコマンドラインで行わなくてもよく、登録したリポジトリの更新情報も管理してくれる、よくできたアプリだ。そして、Cydiaそのものが死ぬときはCydiaがデプロイされているAmazonクラウドのリージョンが死んだときだけで、瞬間風速で困ったことになるのは、外部のリポジトリが負荷に耐えられなくなって死ぬとかストールしているときに、更新情報が得られなくてCydiaの画面のなかでタイムアウトするだけだ。Saurikはそのためのバックエンドの改良や維持管理の責任を十分に果たしているとは思う。ただ、それと、ログインに使ったアカウントに対するほぼ無制限のアクセスを登録することとは話が少し違うのではないかと思うのだが、勘違いなのだろうか。

iOSデバイスへの無制限のアクセスを可能にする自由への対価として、個人情報をSaurikに渡すことが妥当かどうかは考えてもよいことだろう。早い話、Cydiaでログインに使うアカウントは普段のGoogleアカウントとは別のものを使えばよいのだが、その場合、もしそれまでに購入した有料アプリやTweaksがあったとしても、それらは（必要ならば）買い直しになる。もしくは、無料のものを取得するためだけに使っているならば（CydiaがiOSのなかを探っているのではない限り）懸念することはないだろう。ただし、Cydiaが動いているということは、Sandbox機能が外されているということだから、任意のアプリがiOSのあらゆる場所をアクセスできるということは考慮すべきとは思う。

iOS 6はTwitterのみならずFacebookとの統合が進み、どこからでもツイートやポストができるし、両方を登録したデバイスでツイートすればFacebookにも勝手にポストされる。

自分のFacebookアカウントで確認してみたところ、TwitterアプリはFacebook上のありとあらゆる個人情報にアクセスするような表示が出た。TwitterアプリはFacebookサイトから削除ができたけれども、Facebook公式アプリはサイトに現れないので、どうなっているかは全くわからない。ただ、Facebookのありとあらゆるところ（設定変更など）が触れなければ欠陥アプリとなるおそれが大だから、すべて許可なのだろう。iOSとFacebookの「深い統合（deep integration）」の意味するところについて、そろそろよく検討してみたほうがいいかもしれない。

LogicoolのタッチパッドT650

Windows 8なんだが、せっかくジェスチャーが定義されているのにマウスでは使えなくて残念なので、現在唯一（いや、MicrosoftのWedge Touch Mouseはどうなんだという話があるが、やっぱりこれはマウスだ。いくら表面でスワイプできてもジェスチャーができるという話は見当たらないようなのだが）ジェスチャー対応している、LogicoolのT650に突撃したわけである。

いかんせん、価格は大問題だ。Apple Magic Trackpadが定価6,800円なのに、これは8,000円近くする。ひとつには、充電式で二次電池内蔵であることと、ペアリングに必要なUSBのBluetoothドングルがついてくるというところの価格差が考えられる。

名刺用紙を買うついでにビックカメラを冷やかしてみたが、うまい具合に在庫切れで助かったが、ここで心にひっかかりが残ってしまった。なにかのはずみでヤフオクに4,000円からで1つ出ていて、参戦したのだが、追い込みでほぼ定価で落札されて終わっていた。すると困ったことに、ソフマップを覗いてみると、1つだけ在庫があったりして、完全に負けである。

さて、で、この商品。

外箱。7,980円である。親切な店員さんがおまけしてくれたがそれでも高い

それなりにずっしりと重みがあり、Appleのアレとはずいぶん違う。ガラスを使っている点と、二次電池の重さがあるような気がしないでもない。

さて、開梱である。上蓋を持ち上げると商品登場、って、まるっきりAppleだが、箱がダークで本体も同じ色なので全然演出効果がない。ああこれね、で終わってしまった。パッケージデザイナの人はもう少しがんばりましょう。

蓋をあけると商品が現れるという、どこかで見たようなパッケージング。

本体の下は、ちょっとした折り紙で2段になっていて、開くと内部に取説と、USBドングルと充電用USBケーブルが入っていた。ドングルはスポンジ状の少し固めのゴムに収まっている。

本体を外すと、下の段にはUSBドングルと充電用ケーブル

当初、このUSBドングルはいらないのではないかと思っていた。Windows 8は2009年版のMac miniを使っているので、Bluetoothは内蔵しているし、Windows 8側でうまくペアリングもやるのではないかと考えて試行錯誤したのだが、どうにもうまくいかない。だめもとでこれをUSBポートに挿すと、あっという間にペアリング成功して関連のソフトウェアインストールの通知が現れた。消える前にと思って押したので写真が撮れなかったが、Windows 8でよくある通知で、メッセージも適切であり、非常に自然に誘導してもらえた。これはWindows 7までのマイクロソフトとは違う、Windows 8ならではのよく考えられたしくみだ。

ドングルをつけてペアリングされると、自動的にソフトウェアがインストールされる

それでインストールされるのが、どうもLogicool独自のSetPointソフトウェアというもののようだ。ジェスチャーなどは、これが面倒をみるらしい。しばらくするとインストールが終わり、デスクトップ画面であればタスクバーになにやらアイコンが現れる。これが設定に関係する常駐アプリのようだ。早速開いてみると、

これまたどこかで見たような設定画面である

 右の写真は動画で、選択している項目の操作を示している。Appleと全く同じ。わかりやすいからいいんだけど。

Windows PCでタッチパッドをお使いの方々は、クリックではなく1本指タップでの操作を好まれるようで、「タップとクリック」がデフォルトの設定だった。僕は1本指タップは嫌いなので、Macに合わせてクリックのみに選択を変更した。クリックするスイッチはAppleと同じく、手前の左右のゴム足のなかにある。だが、これが結構硬く、指先でクリックするというよりは、第一関節の骨で叩く感じでないと、自然な力でスイッチが入るようにはならなかった。このへんの不自然さを嫌って、サイト等でのレビューに不満が多く出ているようだが、Appleのゴムはとても柔らかく、ちょっと指を乗せる感じでスイッチがしっかり入る。ただし、柔らかいので床を刷るとゴムが穴から外れてしまうので、そのときはがんばって押しこみ直す必要があるのがやや難点だ。

どこかの口コミにあったが、スワイプは、最初はマウスと同じく指の方向とは逆向きになっている。設定画面で、下にある[スクロールのオプション]ボタンを押すと、チェックされていない項目があるので、それをチェックすればスマホと同じ動きになる。

ジェスチャーだが、Mac OS X Lion以後のジェスチャーに慣れていたこともあり、非常に満足だ。三本指アップ・ダウンは、アップがスタート画面で、ダウンがデスクトップへの切り替えなのだが、別にMacと違うという違和感はない。むしろ、MacでLaunchPad画面を開くのに、3本指でつまむ操作が結構難しいので Windows 8ならこれでいいと思った。

また、画面両端からスワイプという（タッチパネル画面もしくはタブレットの場合）操作に相当する、パッドの両端からのスワイプもちゃんとできる。チャームを出すのにマウスカーソルを画面の右の上端もしくは下端に動かすというのはストレスだったので、これは助かる。メニューを出すための上からのスワイプもあり、マウスの右クリックという苦し紛れの割り当てからは開放される。デスクトップ画面での、四本指アップでの全画面表示、ダウンでのデスクトップ表示もなるほどと思った。Urbanアプリでなくても、そうやって全画面にして、左からスワイプで切り替えていけばいいし、デスクトップを見たければスワイプダウンで一発だから、マウスカーソルを目で追いかけながらポチポチ操作することはもうやらなくてよいということになる。

できればAppleは次のBootcampでTrackpadサポートをWindows 8向けにがんばってほしいのだが（いまは7用のBootcamp 4.0で強引にインストールしている状態）、それまでは、あるいはWindows用デスクトップを使っていて、Windows 8にしたのに画面に触っても何も起きないとお嘆きの方々にも、多少値は張るがおすすめできる商品だと思った。

もう一度繰り返すけれど、マウスカーソルを目で追いかけるようなUIは、スマホやタブレットがこれだけ受け容れられた現在では絶滅していいと思っている。ジェスチャーと、おおざっぱな場所のタップで操作できるアプリがPCにもやってくれば、マウスカーソルというものはなくなっていいはずだ。

まとめとして、よくある、Pros & Consでしめる。

Pros:

• 大きさはAppleのMagic Trackpadと同じ表面積で、ジェスチャー操作するには十分な広さがある。
• Appleのアルミの指ざわりと違い、表面にガラスを使っているのでスマホ的な印象がより強調されている。多くの人はガラスのほうが心地よいと感じるのではないか。
• 添付のUSBドングル（同社のキーボードやマウスと共通なので、それを持っていれば流用可能）さえ使えば、ほとんど考える間もなく使えるようになる。たいへん優秀。
• ジェスチャーは素晴らしい。

Cons:

• Appleのが傾斜があるのに対して、こちらはほぼ水平である。そのため、Apple製品と較べて、パッドの上のほうに指が届きにくい感じがする。
• 専用ドングル（Unifyingレシーバーというらしい）必須というのはやや厳しい。標準のBluetoothを使う方法はないものか。
• 充電式なのはよいが、結局充電ケーブルを挿しっぱなしにして使うような気がする。そうなると、Bluetoothであるメリットはどこ?という感じがしないでもない。

問題だったWebKitのバグはiOS 6.0.1で修正されたそうだ

先日やられたWebKitのバグは、きちんとAppleに伝えられ、iOS 6.0.1で対策されたようだ。threatpostが伝えている。

Apple Patches Kernel, Passcode Lock and WebKit Flaws in iOS 6.0.1

https://threatpost.com/en_us/blogs/apple-patches-kernel-passcode-lock-and-webkit-flaws-ios-601-110212

そもそもカーネル内部に入り込める脆弱性があったというのは驚き。kext用に用意してあったOSBundleMachOHeadersというキーでカーネル内部のアドレスを取得でき、そこはADSRしてあっても直接アクセスできるから便利という話のようだ。

Passcode LockとPassbookの関係は各地で既報の通り。デザインの問題と思う。

最後のWebKitの問題で、僕がやられたのはおそらく前者のJavaScriptの配列の扱いに関するものだと思われる。どうやらここに何らかの脆弱性があって、細工したJavaScriptを食べさせれば任意のコードが実行可能だったらしい。

後者はSVGに関するコードに、ダングリングポインタを放置しているところがあるらしく、当然戻り先がおかしくなるのでSVGを含むページをうまく細工して任意のコードを実行させるという話。

とりあえず、すでに攻撃コードが配布されている脅威は対策されたということなのだろう。

ただ、iOS 6.0.1もまだWi-Fiに問題があるような気がしている。6.0は問題外だったが、アンテナ立ってるのに通信しないケースが、まだ6.0.1にも残っている感じがする。そこで、Apple税を払っているので6.1 beta 1にしてみたら、結構いい感じ。iOSに関してはいつものことだが、6.0より軽くなっている感じがする。

いい気になってiPod Touch 4GだけでなくiPad 3までiOS 6.1 beta 1にしたのだが、WOWOWのオンデマンドアプリがiOSバージョンチェックで動かなくなってしまったというオチ。いやはや。

Googleアカウントの2要素認証

Apple IDはなんとか復活させてもらった。クレジットカードの不正利用の疑いも、Visaに確認したところ、Google Driveの有料サービス（25GBで$2.45）を8月に使用し始めたのだけれども、その返金が、10月分の請求の翌日にあったということだった。簡単に言うと、勘違いだった。

Appleはクレジットカードの破棄を薦めるが（当然だと思う）、こちらは家庭の事情があって不可能なので、詳しく様々な事情を説明し、不正利用ではなかったことも合わせて説明して、特例として認めてもらうことができた。社のポリシーとしては疑わしければ（顧客の金銭被害を助長する可能性があるめ）ブラックリストに入れ、そこから外すことはないとのことなので、読まれた方は、説明すればカードを再度有効にしてもらえるのだとは期待されないでください。

というわけで、やはりネットのアカウントを狙う様々な手口があることを身をもって体験したので（まさかiPadにマルウェアが入るとは思わなかった）、Googleアカウントのセキュリティ向上のため、2要素認証を有効にすることにした。

やりかたは、

https://accounts.google.com

にアクセスし、そこから左側の縦のメニューで上から3番目の「セキュリティ」を選択し、中央列に現れる項目のうち、2番目の「2段階認証プロセス」の「ステータス」をONにする。

このとき、たしか携帯電話の電話番号の確認があったように思う。これはどういうことかというと、普通にメールアドレスとパスワードで認証をかけたのち、そのサービスとひもづいた一時パスワード（数字6桁）が、ここに登録された携帯電話に通知されるという、2番目の認証があるから。

これは、サービスごと、Googleサービスを参照する個別のアプリごとに電話がかかってくるので、不正なアクセスがあればすぐにわかるという仕掛け。逆に、いったん電話で合成音声で言われた数字を入れてしまえば、自分（同じPCまたはデバイスの同じアプリ）が使う分には電話はかかってこない。

なので、ログインする際には携帯電話を近くに置いておき、ガラケーで折りたたみ型の場合は開いた状態にしておくという準備をしておくべきだ。なぜなら、電話は遅くても3秒以内にかかってきて、数字は2度言われるが、決してゆっくりした話し方ではないからだ。周囲がうるさい場所では諦めたほうがいい。携帯を片手に、数字キーに指を置いて、言われるままにそのまま入力し、2度目はそれを確認するだけ、というのが望ましい。

失敗した場合は、再度電話をかけさせることができるので、落胆することはない。もういちどログイン画面に戻って入力すれば、別の番号で電話がかかってくる。

なお、最初に使うときは英語のメッセージでかかってくることがあるので、英語が苦手な人でも慌てないように。最初に、「Google認証システムをご利用いただきありがとうございます」という言葉が述べられ、いったん少し間があったあと、「番号は」と続き、あとは数字を6つ、2回言うだけだからだ。ワン、ツー、スリーがわかる人なら大丈夫だと思う。英語では、最後に「サンキュー」と言って切れるが、日本語の場合はもうすこし丁寧な挨拶で切れる。言語の違いは、認証画面の表示が英語か日本語かで区別されているようだ。言語に関係なく、すべてアメリカからの国際電話。

さて、Googleの認証を、ブラウザ画面で行っているとか、アプリ内でブラウザを起動している場合にはこれでよいのだが、アプリが独自のログイン画面を用意している場合は、数字の画面に遷移しないので、電話がかかってこなくて、「アカウントの設定を確認してください」のようなエラーが出るだけだ。このような場合は、ブラウザから一時パスワード（英字16文字）を作成させ、それを自分で決めたパスワードのかわりに入力すればよい。

やりかたは、さきほどの「セキュリティ」画面の3番目の項目、「アプリケーションとサイトを認証する」の[編集]をクリックし、再びGoogleアカウントのパスワード（自分で決めたもの）を入力すると現れる画面の、下半分に注目してほしい。箱で囲まれた、入力欄があるはずだ。ここに、アプリやマシンなどを区別する自分で決めた名前を入力し、隣のボタンを押す。すると、画面が切り替わって、4文字ごとに空白が入った16文字の英文字が表示された、背景つきの大きな枠の画面に切り替わる。この16文字（空白は省略してもしなくても、どちらでもよい）が、アプリに入力する一時パスワードだ。

独自のアカウント設定画面をもつアプリすべては、こちらを使えば解決する。電話の場合と同じように、アプリごとに違うものを入力しなければならないので、さきほどの入力欄には、アプリ名とコンピュータ名を必ず入れるようにしておくと、次に同じ画面にきたときに、画面最下部に一覧されたときに区別がつくので、よいと思う。

こうした、アカウントのパスワードが盗まれた場合の次の防御は、考え方としては比較的よいことだと思われる。Googleアカウントのみですべてがいっぺんに奪われることを防ぎ、アプリ、サービスごとに区別された、次の防御があるからだ。

もちろん、この画面がフィッシングだったら意味はないが、アカウントを作らせるサービスの場合、参考にしてよいものではないかと思う。特定のサービスがやられたとしても、個別に「無効にする」ことができるので、パスワードを変更したあとには、いったんすべて無効にして再度2段階認証をやるべきだと思う。

なお、スマホなどの場合には、認証パスワード生成アプリがあるらしい。

http://support.google.com/accounts/bin/answer.py?hl=ja&answer=1066447&topic=2784804&ctx=topic

ここに、機種ごとの説明がある。

Apple ID乗っ取り

いまのところ金銭的な被害はなさそうなのだけれど、Appleがかけたロックを外すための入力事項がどれも使えない状態。登録情報を書き換えられてしまったら、何らかの問題報告（僕はiCloudに関してのその他の自由入力を使った）をサポートページから伝えなければならなさそうな感じ。

リテールストアのGeniusが対応してくれるのかどうかはわからない。

ただ、PayPalにも変な金銭の出入りがあるし、まぁ、いろいろとやられているような気配。ちなみにPayPal IDはApple IDとは何の関係もないので、前回のマルウェアでなにか履歴でも抜かれたのかもしれない。

JavaからKinectを使うプログラム例をお探しの方へ

とある経緯があって、PrimeSense社のKinect用無償配布ミドルウェア「NiTE」のJavaインタフェースについての解説を探して見つけ出したので、こちらにリンク。

ひとつ前置きしておくと、NITEは骨格座標だけでなく、もっと高度なモーションに関する処理を担当してくれるライブラリで、マイクロソフトのKinect for Windows SDKに近い機能が実現されています。OpenNIはオープンソースなので、C++, C#, JavaなどのAPIが公開されているのですが、NITEに関しては、PrimeSenseのカタログではJavaにも対応していると書かれているものの、どうやって使ったらいいかはどこにも書かれていませんし、ソースもドキュメントも非公開なので、PrimeSenseと契約して魔法少女…もとい、ライセンスかなにかを買わない限り、誰かが使った例を読む以外に具体的なプログラムを作る方法を知ることができません。

それを解説した本が、現在タイで教鞭をとっていらっしゃるらしいAndrew Davison氏の著書「Kinect Open Source Programming Secrets: Hacking the Kinect with OpenNI, NITE, and Java」です。Kindle版は$15ぐらいで結構お安いのですが、どうも地域制限がかかっていて、USでしか買えないようです。

ただ、著者がこの本のドラフト版＋最新情報の追加をしたPDFをご自身のサイトで公開されています。

http://fivedots.coe.psu.ac.th/~ad/kinect/index.html

ちゃんとJavaでサンプルが書かれており、NITEを使ってモーション認識する例が記述されています。

ご自身のプロジェクトがJavaで作られており、Kinectに対応させたいとお考えでしたら、参照されるとよいかと思います。

WebKitのセキュリティホールにやられたorz

YahooメールのspamをiPadの「メール」から削除しようとしたら、プレビューが表示されて、以後3分ぐらいに一度、「Macのメールウイルス対策には...comへ」の日本語アラートが数分おきに現れるようになった。iOS4まで標準だったアラートなので、[OK]を押すまで他のことは何もできない。とりあえずこのアラートは、「設定」の「通知」で空白アイコン、無名のエントリを「オフ」設定にすることで出なくすることはできたが、たいへん気分が悪い。

おそらくプレビューでWebKitが呼び出されて、WebKitのセキュリティホールを使って何らかのトロイの木馬が仕込まれたのだと思う。メールを開いたつもりもなく、「編集」で削除しようとしただけでプレビューが出たように記憶するのだが、もしかしたらタップして踏んでしまったのかもしれない。

iOSは5.1.1。6には事情があってまだしていない。

きょうのthreatpostの投稿に、iOS 6にも存在するWebKitのexploitの説明があったので、例によって超訳することで鬱憤を晴らすことにする。なお、WebKitなのでAndroidのChromeでも踏めるらしい。もしかしたら、少し前にMac OSのSafariがアップデートされたがそれに関係があるかもしれない（アラートの文面からしても、Mac OS X Mountain Lionの「通知」でこれを表示させたほうが効果的な気がする）。

（2012年11月12日追記：このexploitとPOCはApple側で認識され、iOS 6.0.1で対策されたようだ。僕は早速アップデートした。事情があって上げられない人とかいるかもしれないが、乗っ取られるのとどっちをとるかよく考えたほうがいいと思う）

原文はこちら：

https://threatpost.com/en_us/blogs/iphone-5-launches-hackers-explain-journey-working-exploit-ios-6-092112

----

iPhone 5出荷開始、iOS 6でも生きているexploitへの旅についてハッカーが語る

threatpost - Apple

Michael mimoso
2012年9月21日

AppleのiPhone 5を待ちわびて今日まで行列を作って泊まりこんだ数万人と同じ時間、ハッカーたちはすでにそのコアであるiOS 6オペレーティングシステムを配下に置いていた。2人のオランダ人ハッカーたちはAppleの頑丈な防壁をうまくやりすごし、今週アムステルダムで行われたEUSecWest会議で「iPhone 4Sにパッチを当てるハック」に最初に成功したことをプレゼンした。このexploitは、いままさに登場する新しいデバイスについても有効なものだ。

Joost PolとDaan Keuperは数多くの賞賛と、$30,000を、このmobile Pwn2Ownコンテスト（注：Pwnはオンラインゲームでの勝利、Wonをチャットでミスタイプしたことから広まったもの。ここでの勝利はクラック成功を意味していて、Pwn2Ownとは、クラック成功者に商品授与するイベントを指す）勝者にその努力を報うものとして授与された。この2人は、オランダのセキュリティ会社Certified Secure社の研究員で、WebKit、つまりAppleのSafariブラウザの下敷きになっているブラウザエンジンの脆弱性を利用した。3週間の価値ある労働を経て、このペアは携帯からデータを盗み出すことのできる、生きているexploitを見つけ出した。本ブログはPolとKeuperに、どうやって彼らがiPhoneを首尾よくクラックしたのか尋ねてみた。

Threatpost: iPhone 4S（とiOS 6）をターゲットにした動機は？

Pol and Keuper: iPhoneには考えられる最善のセキュリティ機能（例えばASLR - アプリのメモリ割り当て空間をランダムにする, DEP, サンドボックス、コード署名など）を備えていて、なにより僕たちにとって最も興味深いターゲットだったから。iOS 6のリリースについては、WebKitの新しいバージョンが使われていて、以前の脆弱性やexploit経路はふさがれていると思っていたから、おまけでついてきた関心といったところ。

Threatpost: 君たちが発見した「WebKit脆弱性」（注：今年8月末の同ブログ記事で、WebKit脆弱性を嘆くコラム）はどの程度深刻で、それをどうやって見つけたのか説明してくれないか。

Pol and Keuper: 脆弱性を発見したのは、WebKitのコードの検査をする過程からだった。脆弱性の程度は極めて深刻で、（若干の罠を仕掛けておけば）任意のコード実行が（Safariのサンドボックス内で）可能だ。僕たちがPwn2Ownで実演したように。これを活用すれば、（例えば）誰かの個人的な写真やアドレス帳やブラウザの履歴に直接アクセスすることができてしまう。

Threatpost: 「WebKitのセキュリティ」（注：今年2月にRSAカンファレンスで講演されたAndroid携帯のWebKitが持つゼロデイ脆弱性の悪夢についての記事）の話について、君たちはどんな意見を持っている？

Pol and Keuper: 不完全だと思う。現時点で、僕たちが見つけた脆弱性の詳細について話すことはよいことではないと思うし、WebKitのセキュリティ全般（そして競技のルール全体やその他すべて）についてもそう思う。でも、僕たちがexploitできる脆弱性を3週間以内に見つけられたという点で、この「不完全な」話は極めて強い意味を持つことになったと思う。

Threatpost: 脆弱性を発見してから、君たちはいくばくかのコードを継ぎ合わせて、生きているexploitに仕上げてしまった。それはどんなもので、なぜそんなことをしなければならなかったのか話してくれないか。

Pol and Keuper: 脆弱性があったからといって、それが「直接」コード実行に結びつくことは極めてまれだ。ほとんどのexploitは、コード実行を可能にするために、あなたが言う「追加の作業」がある程度必要なんだ。僕たちのケースでは、iOSの機能であるコード署名（Appleが付与する署名なしではいかなるコードも実行できない機能）に対するワークアラウンドも必要だった。

Threatpost: Appleのコード署名に対して、どんな細工をしたのかな？　難しかった？

Pol and Keuper: 普通、iOSではコード空間のあるページに対して、実行可能か書き込み可能かのどちらかしか許可していない。両方の権限がつくことはありえない。また、対象となるページは実メモリにロードされる前に署名されている必要もある。これはとても厳密な規則で、（注：セキュリティにとって）非常によい働きをする。iOS 4.3以後、Appleはこのポリシーを導入した。

iOS 4.3以後、Appleがそれを決めたのは、Mobile Safariブラウザのパフォーマンス向上のためにJust In Time (JIT)コンパイラを導入したからだった。だから、いまではMobile SafariはページにRWX（注：読み書き実行）をマップできる。この例外はMobile Safariだけのために与えられた（つまり特権を持っている）。僕たちのexploitでは、JITページのロケーションを見つけ出して自作のシェルコードを上書きし、そこへジャンプする。

もしJITページがなかったら、ROP [return-oriented programming]を使って全く同じ結果（つまりコード実行）が得られるようにしてやる。けれど、ROPのペイロードを作るのは実にまったくしんどい作業だ。

どちらも既知のテクニックで、以前にも利用されたことがあるものだ。

Threatpost: そのexploitを働かせるためには、利用者をうまく釣って携帯から悪意あるサイトを観るように仕掛けるの必要があると思うんだけれども、それはどうやるの？

Pol and Keuper: exploitはバックグラウンドで動いて、ひそかに利用者の個人データ（アドレス帳、カメラで撮った写真、ブラウザ履歴など）を携帯から外部のサーバに、攻撃者の指示で送信することになるだろう。

Threatpost: 君たちの仕事では、iPhoneからemailやSMSメッセージを取り出すことはできなかったようだけれど、それはどうして？

Pol and Keuper: Safariのサンドボックス（つまり僕たちのコードが動くところ）からはSMSやemailのデータベースにアクセスできないんだ。

Threatpost: 今回のexploitはiOS 6にもそのまま残っていて、iOS 6でも同じexploitが働くという理解でいいのかな？

Pol and Keuper: 今回の脆弱性はiOS 6にそのまま残っている。exploitに対する一般的なアイディアも同じだ。けれど、iOS 6では少し異なった中間作業が必要になる。

Threatpost: 君たちはexploitを破壊した、ということだけれどそれは本当なの？　どうして？

Pol and Keuper: 本当だ。そんなものは、もはや不要だろう？　競技のルールのなかに、脆弱性の説明と簡単なPOC（コンセプトを証明する）プログラムをZDI [TippingPoint's Zero Day Initiative program]へ送る必要があった、それだけのこと。

Threatpost: その詳細はAppleと共有している？　やりとりはどんな感じだったの？

Pol and Keuper: 競技の規則の一部に、脆弱性はZDIからAppleに開示されると明示されている。
----

イオシスがまたやってくれた

昨日は久々の東京出張だったので、秋葉原を散策。本当は、分解して取り出した古いVAIOの液晶ディスプレイを再利用したかったので、Aitendoさんの店舗で相談するつもりだったのだが、ピンポイントで木曜定休にはまり、シャッター越しに暗い店内を覗きこむような形になった。残念。めったに東京出張できる身分でないので、通販で相談するしかないか。

しかし、末広町駅西側があんなことになっているとは思いもよらなかった。公には書けないが、要するに中国のテクノロジーやそういった2ch的なもろもろが微妙な感じで、あっさりいえば商売になっているということ。世の中がなんでもクリーンならばよいとは全く思わないので、とりあえず見逃してもらえていることはよいことだと思う。また、価格的にもネットの裏商売のようなひどいものではなく、適正な利益水準と感じられたので、当局の方々におかれましては、今後ともお目こぼしいただきたいと願う次第。

そんなこんなで魔境を延々と彷徨っていたため、いつもの共立・秋月の通りに到着するまでかなり時間がかかったのだが、秋月の隣にあるイオシスは例によって一応みておくことにした。

ioBook Airについては以前にも書いたが、場所を微妙に裏側に変更して販売継続中のようだ。しかし、10月26日のWindows 8販売開始以後、あの価格で勝負ができるとは思えないのでそれまでになんとか売り切ったほうがいいような気がした。

今回目にしたのは、キーボード。ひとつはApple Bluetooth Keyboardのなんちゃって版と、驚いたことにHappy Hacking Keyboard風のなにか、であった。

前者は、ioBook Airよりはましだが五十歩百歩な感じの品物だ。アルミ素材も似ている。金型の精度も似たり寄ったりな感じだ。1,980円だったように思うのだが、その程度のものということ。特に、チルト用の脚はあまりにもひどいので、Apple製品と較べてはいけない。それなら、末広町魔境にある別の同価格のものを検討すべきと思われる。

で、Happy Hacking Keyboard風のなにか、であるが、これも大変に残念なものと思われる。キータッチは普通のメンブレンで、まぁどうということはない。配列は一応USなのだが、なぜか106キーボードの風情が漂う。スペースキーが短いのだ。で、英数キーのところはMacのコマンドキーのマーク、かなキーのところはイオシスのロゴが入っている。

1000円台でコンパクトなUS配列のキーボードはなかなか入手困難なので、そんな要望にはひとつの解決になるかもしれないが、スペースキーが日本語キーボード並に短いのは耐えられない人が多いと思う。これは各自、実物を触って確かめてもらいたい。

ついでなので中華Padもいくつかの店舗に並んでいるのを見たのだが、中華Padもちゃんとしたものが主流となりつつあるようで、1万円台ではせいぜいAndroidも3.0程度、ICSやJerry Beanを動かすなら2万、3万といったところで、それならNexus 7買っちゃえばと感じられた。Nexus 7を初めて触ったのだが、Androidマシンの無駄にハイスペックなSoCとJerry Beanになってようやくまともになったなめらかな表示で、正直、驚愕してしまった。これなら使ってみたいと、Androidなのに初めて思った。予算が余るなら、買ってしまうかもしれない。安いし。ええ、間違っても自腹では買いません。Androidなんで。

SONY DCR-TRV900 mini DVカメラをiMovieで認識させる

Mini DVで持っていたテープの内容を発掘するために、手持ちのSONY DCR-TRV900をMac mini mid 2011に「Thunderbolt to Firewire Adapter」に接続してみた。

ところが、この機種は昔VAIOでもうまく認識されず、ケーブルを選ぶところがあった。案の定、Macはカメラを認識してくれない。こういうときは検索ということで、Appleのサポートフォーラムがひっかかったが、理由はよくわからないがうまくいったりいかなかったりするようだ。

困ったなと思い、接続したままカメラの電源を入れたり、VTR側に切り替えたり（テープを再生したいのだから、VTR側が正しい）するのだが、どうもうまくいかなかった。

システムの詳細をみても、カメラは見あたらない。

そこで思い立って、VTRでオンにしたままi-Link端子のケーブルを抜いて挿しなおしてみたところ、いきなりiMovieにDVカメラのウインドウが開いた。要するに成功したということ。

何にせよ、理由がわからないのは確か。お困りの方のご参考になればとここに記しておく。

なお、iMovieでの「自動」取り込みは、無録画からはじまるテープではうまくいかないようだ。僕はテープの先頭部分は信用していなかったので、少し送ってから使うようにしていた。この場合は、「手動」で録画されているところの頭まで巻き戻してから、おもむろに「取り込む...」を押すとよいようだ。

Emacs 24.2をMac用にコンパイルする

いままで使ってきたEmacs23、ふと思うところがあり、思い切ってGit Headをもってくることにした。きょうのバージョンは24.2.50だった。

そのまま./automake.sh && ./configure --with-ns && make bootstrap installでもよいのだが、おなじみinlineパッチとLion Full Screenパッチをあてることにした。

どちらもEmacs24ではあるが、inlineパッチは24.50、Full Screenパッチは24.1を対象にしたもの。結論からいうと、あまり問題にはならなかった。

先にFull Screenパッチをあてるといいと思う。こちらは行が若干前後するだけで、パッチはきれいにあたる。一方、inlineパッチは、最初がconfigure.inに対するパッチで、これはGit Headには存在しないので、./automake.shしてconfigureを生成してからpatchコマンドを実行することになる。すると最初にファイル名を問われるので、そこで「configure」を入れてやればよい。1つだけrejectが出るが、inlineパッチで追加したmacim.mのオブジェクトを追加するところ。rejファイルを見て、その前にある"nsfont.o"を検索して、そのあとにmacim.oを追記してやればよい。

なお、sourceforgeに置かれているinlineパッチは、インストール時のOSのLocaleを見ているので、英語設定でインストールして、システム環境設定で言語を日本語に切り替えた場合、ことえりなど日本語IMEを見つけてくれない。MacEmacs JPメーリングリストの記事にある、現在選択されているLocaleが日本語なら日本語IMEを探すようにしておくほうがいいかもしれない。

make installまでやると、nextstepディレクトリの下にEmacs.appとして一式揃っているので、/Applicationにでもmvしてやればよいと思う。というか、そうした。

最後にいちばん苦労したのは、.emacsが結構違うということだった。さまざまな議論があちこちにあるけれども、Mac Wikiの説明がいちばん有用だと思う。あまり詳しいコメントはついていないが、Emacs Lispを少々かじっていれば何をやっているかはわかるはず。個人的にはSection 6の、文字の拡大縮小（\C-+,-,0）に対応したフォントの設定がたいへんありがたかった。いままで12ptで、さすがにThunderbolt Displayの27inchには文字が小さかったので、14ptになって助かっている。また、ここのブログエントリでも苦労が明かされているが、「(setq default-input-method "MacOSX")」の行は、画面の各種設定をやった後に置かないとinlineパッチで期待される動き（toggle-input-methodがIMEのオンオフと連動する）をしないようだ。ここはEmacs23までとは大きく違う、おそらくパッチで何らかの手立てが必要と思われる部分と思われるところなので、当面注意しておくことをおすすめする。

（2012年9月7日追記：Emacs23以後はUnicodeのIVSに対応しているような話があったが、どうもこれはLinux上での話のようだ。つまり、--with-nsでCocoaを使った場合とは違うようだ。そこで--with-Xをつけてコンパイルしようとするが、libotfを組み込んでくれない。理由はpkg-infoでまずlibXftを調べ、そのあとpkg-infoでfreetype2の存在を調べてからpkg-infoでlibotfを調べるからのようだった。作ろうとしたのがHomebrewを使っているMacだったので、Xquartzに入っているものは普通にはインストールしない。強引に作るにはconfigureを書き換えることになるが、面倒なのでやめた。）

Kindle Previewすごい

作家の藤井大洋さんのSF作品「Gene Mapper」はDRMなしで各種電子書籍フォーマットを用意して販売されている、電子書籍について関心のあるSF者には見逃せない作品だ。

作品は、サイバーパンク的要素の強いハイスピード展開、テクノロジー満載の楽しい内容なのだが、いまサイバーパンクと書いた理由は、みっしりと振られたルビ。もはや古典の「ニューロマンサー」を彷彿とさせるものだったから。また、藤井氏はルビや圏点を意欲的に使い、英語の横倒しセンテンスに漢字かな交じりの日本語ルビ、日本語に英語横倒しルビ、まだ読んでいないがベトナム語に日本語ルビの箇所もあるらしい。当然英数字も増えるので、縦組みの場合は縦中横も頻発することになる。

で、Kobo TouchがWebKitに手を加えたNetFrontでうまく表示するのはともかくとして、さきほど藤井氏のブログエントリで、「Kindle Preview」という著者が実機でどう見えるかをPC上で確認するためのソフトウェアがKindle Touchの縦組み表示に対応していることを知り、Koboブックストアで購入した「Gene Mapper」のKEPUBを読み込ませてみた。

CaribreでMOBIにしなければ読めないかと思ったのだけれども、最初の画面でEPUBも読むと書いてあったので、DRM Freeな氏の作品をそのまま読み込ませたという経緯。

するとやはりMOBIに自動変換するようで、詳細画面を開くと、日本語で「コンパイラ」のバナーが出た後、変換処理の進行状況が現れ、いろいろと警告やエラーメッセージを出しながらもMOBIに変換し、完了したという表示が出た。すると、いままでグレーアウトされていた[OK]ボタンが押せるようになり、目次のページが開いたのだが、とにかく素晴らしい品質の縦組みをする。

本文に入れば、行末の揃えはもちろん禁則や追い込み、ぶら下げなど日本語組版のややこしいところをきちんとクリアしている。もちろん三点ダッシュや連続するダーシもきちんとつながっている（ChromiumやSafariでは、文字の間が少し空いてしまう）。本作品の特徴である大量のルビも、普通に印刷物で読むような、うまい配置をする。ルビの配置についてはもしかすると作家がCSSをうまく書いているためなのかもしれないけれども。

とにかく、この品質であれば、Kindle日本語版には十分期待していいと思う。実機の販売が楽しみだ。

なお、役物が連続するところでの空白はKobo Touchと同じだった。もしかするとKindleもWebKitを使っているのかもしれない。

Kobo TouchはGoogle Analyticsにデータを送信しているらしい

MobileReadのフォーラムを眺めていたら、こんな記事があった。

KT's Google Analytics integration, and how to disable it.

おやまぁ、最悪〜。Googleのサービス使いながらAnalytics宛はすべてfirewallで遮断している僕にとってはほっておけない話。超訳してみる。
----

• KTがオンラインでGoogle Analyticsにアクセスできるときには利用データを送信している
• 1.9.16からじゃなくて、最初のファームウェアからそうだったよ
• 利用データの内容は、例えば「ホームスクリーンが@timeにロードされた」「読書画面が@timeにX分開いていた」「デバイスは@timeにスリープした」など
• 機内モードにずっとしとけばデータは送られないけど、WiFi経由のアップデートのときにデータは送られちゃうかもね
• 電源を切るか再起動するまでひとつのセッション（それか500個のデータがたまるまで。ただ、そこでログを止めるのか新しいセッションになるのかは不明）
• 送信されないでたまっていたデータは再起動のときにクリアされる
• ひとつのセッションの間、ランダムに与えられたユーザIDが共通して使われる。セッションをまたいで同じIDが使われることはない
• クレジットカード番号やペットの名前や読書中の本やメールアドレスがGoogleに送られることはない（これはやってあるよね？）
• Kobo社はあなたのIPアドレスやあなたのKoboアカウントと関係する行動は見ることができないけど、Googleはそれができる。間違いなくIPアドレスは記録している
• データがGoogle AnalyticsからKoboに転送されているわけではない
• データ送信は内蔵ブラウザとは関係なく行われる
• devices.kobo.comはまやかしだ（後述）

.kobo/Kobo/Kobo eReader.confの変数GAQueueに、次回KTがネットに接続するまでのGoogle Analyticsに送信するデータがたまってる。GAQueueは再起動ごとにクリアされる。

GAQueue変数のなかみを読み解きたいなら、以下の文書を参照：
最もわかりやすいやつ、GAのcookieについて、utmsのパラメタについて

ナード向けに具体例を置いといた。
http://pastie.org/3079390

KTは「http://devices.kobo.com/ReadingView/Book」みたいなURLをGAに送るけど、devices.kobo.comは存在しない。これは実在しないし、だからといって悪いやつが「隠蔽の証拠」にしようとしたわけでもない（もしそうなら設定ファイルのなかみは難読化するはずだし、KoboのCEOはもっと儲けてるはずだ）。

Google AnalyticsはWebサイトをモニタするためにあちこちのサイトに組み込まれている、簡単で、無料のプラットフォームだ。Kobo端末はGAに対して、自分がWebサイトを見ているような形でデータを送ってる。彼らが使っているのは、ここにあるような、モバイルデバイス用GAと同じやりかたを使っている。

Lanchtrayが言うように、デバイスが利用状況を測定するのは別に驚くようなことじゃない。だけど僕は彼らがモバイルゲームを例にとって、詳細なスタッツ（どんなオプションを使ったかだとか）は必要で有用だというのには納得しない。

僕はKTがGAと統合されているってのはしばらく前から知ってたけど、いまその実装をしっかり見て、詳しいスタッツについて考えてる。でも、KoboがGAが提供しているツールのような、ひどく押し付けがましくて、使いものにならないトラッキング情報のほとんどを避ける努力をしているのが見て取れて喜んでる。Koboはアカウントや明白なIDを追跡しないし、セッションをまたがる（再起動しても追跡する）データは送信しない。

だけど、ホームスクリーンをロードしたり、本をX分読んだとかいちいち報告されるのは僕にとってはオーバーキルだ。測定しているのは、すごく深い情報をとられるってわけじゃないし、CarrierIQがやったみたいなこととや、メニューやボタン操作の追跡をされるのとは程遠いんだけど。

要するに、少なくとも僕にとっては、「気持ち悪い」の一線を超えてるんだ。だって、データはGoogleに送られて、スタッツはGoogleの個人情報保管庫に入れられて分析されるんだ（これがKoboに送られるんだったら、やっぱり考えるけど、かなりましだ。Koboは個人情報の収穫でビジネスを立てているわけじゃないから）。

Marco Armentは、僕よりずっとうまく「モバイル分析が気持ち悪くなる境目」について説明してる（49分目以後、コーヒーの話が終わったところから）。

Kobo TouchでGoogle Analyticsを無効にする方法

たったこれだけ：Kobo Touchのhostsファイルに、www.google-analytics.comがループバックアドレスの127.0.0.1を指すように書いておく。これでデバイスはGoogle Analyticsとは通信できなくなるから追跡を断ち切れる。

正確には、/etc/hostsファイルに

127.0.0.1 www.google-analytics.com ssl.google-analytics.com

と追記した。

（以下アップデート用ファイルとその適用のしかたが説明されてるけど割愛）

この仕掛けはアップグレードに関係なく有効だと思う。開発者がhostsファイルを更新するってことは考えにくいから。

（以下、擁護派のLanchtrayとその他の人の間で議論があるけど割愛）

----
（2012年9月3日追記：PCのKoboアプリもGAと統合されているようだ。Mac版には、~/Library/Preferences/com.kobo.Kobo Desktop Edition.plistというのファイルとcom.kobo.Analytics.plistがある。バイナリなのでコピーしてXML形式にすると、前者にはBrowser.cookiesというキーで、b64エンコーディングされたバイナリの配列がある。そしてその次にはGoogleAnalytics.visitorCookieというキーでなにやら数字とドットの組合せからなる長い文字列が値としてついている。後者にはただひとつだけのエントリがあり、キーはGAQueue、値は配列のようだ（いまは空だった）。）

Kobo TouchはCoretex-A8開発ボードらしい

@h_kenkenさんのツイートを追って、単なるブックマーク。

まず、日経ITProがKobo Hackについてまとめた記事。Raspberry PIを前フリにしてさっさとKoboの分解に進む潔さが好ましい。Kobo Touchだが、昨夜ヤフオクを見たら、ついに1000円台で投げ売っている人もいた。多くは5000円を切っているので、いまの騒ぎが続けばKobo Touch（ただし開発ボードとして）複数持ちという人も増えるのではないかと思う。

もうひとつは、MITOUJTAGを使った、どう考えてもKobo Touchを念頭に置いたとしか考えられない、iMX508のバウンダリスキャン事例紹介。ここまで可視化して内部を追えるというのがすごいなぁと感心。意外だったのは、MITOUはIPAの「未踏プロジェクト」とは何の関係もなさそうなこと。よく見たら、正式名称は「未踏ソフトウェア創造事業」で、ハードウェアごりごりするのは少し違うみたい。FPGAのHDLだってソフトウェアじゃないかのとかいうのが筋違いなんだろう。

KEPUBとはなにか（Kobo EPUB）

給料日までに少し財布に余裕があるような気がしたので、Koboブックストアで日本語書籍を購入してみた。それまでは、カナダのサイトで購入した英語の本とか、O'ReillyのDRM FreeのEPUBを入れていたので、日本語書籍は初めてだ。

それでようやく気づいたのだが、Kobo Touchの日本語書籍はACCESSのWebKitを使わなければならないから、従来のnickel（Kobo Touch内部のLinux上で動く読書アプリ）のレンダリングエンジンではなく、NetFront BookReader EPUB Editionを選択しなければ、日本語組版として破綻することになる（はず）。

Kobo Touchは、村上真雄氏のエントリにあるように、ファイルの拡張子で従来のEPUBのレンダリングエンジンとEPUB3対応レンダリングエンジンを切り替える。拡張子が単なる「.epub」なら前者、「.kepub.epub」なら後者ということだ。

KEPUB（Kobo EPUB）は、Koboのブックリーダーに合わせて作られたEPUBというような意味合いになるようだ。つまり、IDPFの規格からは逸脱していないが、他のブックリーダーでの表示は知らないよ、ということになる。

KEPUBについて、MobileReadのWikiの記述は必ずしも正確に記述されていないようだが、KoboブックリーダーとPC側アプリの関係についての記述はとりあえず現状に即している。詳しくは書かれていないが、ここで問題になるのはKDRMという独自のDRMだ。Wikiの記述どおり、PC側アプリやWiFi直接で入手する書籍は、KEPUBのみとなる。そして、KEPUBは3つのDRM方針、つまりDRM Free、Adobe DRM、KDRMの3つで配布されている。具体的にはDRM Freeは、藤井大洋氏の「Gene Mapper」。Adobe DRMは日本語書籍ではまだ確認されていないが、MobileReadのフォーラムには存在するようなコメントがある。そして、伊藤計劃の「虐殺器官」「ハーモニー」はKDRMだった。KDRMは、.kepub.epubをunzipして得られるトップディレクトリのrights.xmlで用いられている要素名なので、便宜的にそう呼ぶことにしている。

KDRMは、他のプラットフォームでは開くことができない。Adobe DRMと同様、ファイル名はそのままで、本文に関わるすべてのファイルが暗号化されており、unzipしても一切内容を見ることはできない。Adobe DRMならばそれに対応した他のリーダーでも開くことができるが、KDRMではそれができない。オープンプラットフォームと考えていたが、版元など権利者の要望及び営業の都合（Kobo独占発売や特価など）で囲い込む仕組みは用意されていたということになる。

カナダのサイトに接続すれば、「My Library」以下はAdobe DRMのダウンロードリンクがついた状態で表示される。しかし、日本語書籍は一切現れなかった。一方、日本向けKoboブックストアの「マイライブラリ」は書誌情報を出すのみ。たしかに日本語書籍はKEPUBで提供しているのだから、Webブラウザから個別に配信を受ける筋合いのものではないだろう。従来のKobo社の方針と齟齬はない。とはいえ、何か腑に落ちないものは残る。

ついでなので、SONY Readerについて誤解していたことをここに告白する。SONY ReaderはAdobe DRMのEPUBのみを扱っているものとばかり思っていた。しかし、日本の製品であれば、また、EPUB3の規格が定まる以前から販売していたのだから、当然日本独自の縦組み可能なフォーマットで本は配信されていたことに気づいていなければならなかった。具体的には、XDMFと.bookだ。日本のReaderストアで扱われている日本語書籍は多くがこのどちらかだろう。紀伊國屋書店のKinoppy以後、EPUB3の書籍もあるかもしれないが、KinoppyもXDMFと.bookに対応しているので何の保証もない。

XDMFと.bookは形式こそXMLに準じているが、シャープもボイジャーも古くから日本語の縦組み読書環境を提供してきた経緯があり、文字コードはシフトJISなのだそうだ。JIS X 0213:2004に対応したShift_JIS-2004というものがあるそうだが、入力システム(IME）が対応しているかどうかは知らない。いずれにせよ、JIS X 0213止まりではまだ多くの文字が「外字」として、XML文書のなかでは「画像」として組み込まれることになる。EPUB3においても、Unicode対応について明確な定めはないようだし、あれば逆に制約になるので、現状はJIS X 0213:2004を逸脱しない範囲のUTF-8ファイルをマークアップすることになるのだろう。実際、楽天Koboをセットアップして最初に入る青空文庫の「吾輩は猫である」には、OEBPS/Image/gaijiというフォルダがあり、ページごとに使われている「外字」がPNG形式で入っている（なぜかKDRMがかかっているので開けないのだが）。

こうした「外字」問題に対しては、特に多くの役物や各種異体字に関しては、2006年のUnicode 5.0でIVS（異体字辞書システム）が導入され、2012年現在Adobe Japan 1-6に対応したグリフを持つフォントならば公式にIVD（異体字辞書）に登録されている文字の多くが、さらに汎用電子コレクションを含めば、現時点で日本語でUnicode 6.1のコードポイントが割り当てられている文字はすべて表示できる。具体的には、IPAmjフォント（明朝のみ）には汎用電子コレクションが含まれ、Adobeの最新のヒラギノはAdobe Japan 1-6対応ということになるだろう。明治の活版印刷に由来し人気の高い秀英体は、2008年の「平成の大改刻」のAdobe Japan 1-5対応版をモリサワが販売しているのが現在最新の状況のようだ。IVSは拡張性のある規格なので、状況次第で今後グリフが追加されることはありえる。ただ、従来の印刷書籍でも作字して、全く独自の文字を版面に加えるということはあったので、そのような場合には画像、特にSVGやWebフォントのようなベクター形式の図形を用いることにはなるだろう。しかし、シフトJISという制約がない分、UTF-8を使うEPUBのほうがXDMFや.bookに比べ「外字」となる文字数は少なくなるはずで、EPUBが望ましいのだが、現在日本語書籍をEPUB3のみで提供しているのは楽天Koboのみ、しかしKDRMで囲い込まれているというのはどうにも釈然としない。

話がそれたついでに、EPUBと外字問題に関しては、先月のセミナーの動画をご覧いただくとよくわかると思う。

Kobo Touchにはオープンソースが似合う

前のエントリに追記を書いていて、別エントリにすべきと思ったのであらためて。

まず、日本語EPUB対応はNetFront BookReader v1.0 EPUB Editionであるということ。これに関しては、下川さんのEPUBに寄せる強い思いもあるだろうし、出版社の要望に沿うためにも日本特有のきめこまやかな（というか、芸術的職人芸に基づく）組版を実現させる必要があって、代わるものがなかったということなのだろうと思う。むしろ、WebKitの現状を考えるに、それを調整する、つまりオープンソースコミュニティに関わっていく時間が、ビジネスの側面から考えると待てなかった側面はやむを得ないのだろう。SONY ReaderはAdobe Reader Mobileを採用しているということなので、競争上、プロプライエタリで、これを超えるものがあるなら搭載することは当然のことなのだろうと思う。

また、様々な使い勝手について、日本の消費者は完璧なものを望むので、もとのKobo Touchに対してソフトウェア的に対応できるものは何でもやっていかなければ今回以上に炎上したであろうことは想像できないことはない。

特に、画面上の操作が赤外線センサであることについて販売員が知らず、スリープ状態ですぐ電池がなくなることに疑問を持ったまま店頭に立っているというのは（いや、きょう某店頭で偶然販売員と会話して知っただけで、全国的にどうなのかは知らない）どうなのかと思ったりした。Appleやソニーのように直売店があるわけではないので、商品のなかみに詳しい必要はないのだろうが、これだけ炎上した以上、苦情の分析に専任を当てて得意のスピード経営で販売員への対応マニュアルを随時更新するとか楽天はしたほうがいいんじゃないかと懸念してみたり。ちなみに、「電源オフ」にすれば赤外線センサを見なくなるのでかばんに入れても電池は減りませんが、スリープ状態では画面上に障害物があるとLEDが点灯するのでぐんぐん電池が減ります。って書いてみたら、デフォルト設定が悪いんじゃないかという気がしてきたぞ。

デスクトップアプリにしても、おそらく出版社の要望にきめ細かく応えた日本語EPUB3の美しい組版を実現するには現状のWebKitはまだ実装が及ばないところがあるので、しばらくは出ないだろうし、出てもおそらくNetFrontのコードを持ち込むことになるだろうから、プロプライエタリなコードがまた増えることになるんだと思う。

そう考えると、Kindle日本語版の「出る出る詐欺」も、組版エンジンの実装とMOBIなりAZWなりのフォーマット改訂に手間がかかっているせいではないかという気がしてきた。その意味では、楽天は率先して前線に出て十字砲火を受けたわけで、あっぱれというほかないと思う。内部筋の情報では三木谷はかなりへこんでいるらしいが、お前が出ずに誰がこんな危険なギャンブル、もとい偉大なる勇み足ができるか、よく考えて、もっとましな開き直り会見したほうがいいのではないか。まぁ、ほとぼりが冷めた頃にAmazonが楽天の失敗の上に満を持して登場とかありうるわけだけれどもそこはそれ、先行者利益ということで（ほんまかいな）。

しかし、そうして重厚な品質の上に成り立つのはAppleしかり、大事なところはほとんど外から触れない製品にならざるを得ないわけで、もともとあったKoboのカジュアルなところとは対局になってしまうことを懸念せざるを得ない。例えばKobo書店サイトについて苦情を言う日本人は、従来のサイトを知らないから言えるのであって、あんなに買いにくいサイトはなかった。安いのは若者向けの恋愛小説とかホラーとかの軽いやつばかりで、欲しい本は検索に偶然引っかかっても他の書店のほうが安かったりと、売る気があるのかどうか、あんまり考えてなさそうなところが逆に好感を持ってしまったりするような作りだったのだが。

やはりここは、すでに出ているソースコードをもとに、オープンソースコミュニティのファームウェアをがんばらざるを得ないのではないか。すでに基本はできているので、nickelに相当する部分はWebKitの最新版にしっかり追随する形、もしQtの更新が遅ければOpenFrameworkに置き換えていくぐらいの勢いがあってもいいのではと思った。若者がんばれ。おじさんはもうだめだから。

Kobo Touchをhackする日本人たちに敬意

2ch有志カスタムファームウェアがあるというので、いろいろ探してみたら、Kobo Touch のソースツリー（及びパッチ）が出ているのね。

https://github.com/kobolabs/Kobo-Reader

2年前の最終更新だけれども、製品が出た当時のことを考えれば、まぁカーネルを置き換えるようなことは特にしていないのかもしれないなどと思いつつ。それにしても、Linuxで動いているからにはGPLに従ってソースを出さなければならないわけで、GPL強力と驚きました。いやまじで。

Linuxについては詳しくないので、daemon関係については正直さっぱりなのですが、アプリケーションがQt Embeddedというのもびっくり。電子書籍端末なのでなんかWebKitを使うプログラムが動いているんだろうと思ったら、Qtに含まれるWebKitを使っているというわけですね。ということは、日本語対応はQtを新しくするだけでそれなりに、ということですか。アプリ名はどうやらnickelらしい。

（2012年8月7日追記：日本語EPUBは、イースト社のNetFront BookReader v1.0 EPUB Editionを使っていると、ろす氏のブログに書かれておりまして、氏の立ち位置からして間違いない情報と思いますので訂正いたします。ちなみにNetFrontはACCESSがガラケーや組み込み向けに出してきた、別の意味で歴史のあるWebブラウザですな。イーストは電子書籍業界の有名人、下川さんの会社ですから、かなりEPUB3に思い入れの入った作りであろうかとは想像できます。それから、某有料メルマガ方面から、コストの問題で搭載すべきソフトウェアコンポーネントが別のものになっているという話がきこえてきて、それがもとからあったものなのか、楽天の要望を解決するために購入すべきものが代替物になったのか、そのへんは不明です。ただ、楽天なり日本の消費者の要望で、カラッとオープンだったKoboが囲い込まれた商品になっていくならそれは残念なことだと思います。）
（2012年8月13日追記：NetFront Book Reader v1.0 EPUB EditionのレンダリングエンジンはWebKitだということが、村上真雄氏のブログに書かれていた。氏はEPUB3の縦組みに必須のCSS3 Writing-Modeの規格に深く関わっていた方。他にも、いかにもWebKit的な特徴的なレンダリングが観察されるという言及は複数あり、ACCESSまったくオリジナルのレンダリングエンジンというわけではないようだ。この記事によれば、ACCESSはIDPFメンバーとして、WebKitベースのEPUB3組版リファレンス実装Readiumにコードを貢献し、それが反映されたものがMac OS X用カスタムバイナリとして現在提供されているようだ。つまり、一般的なChomeやChromiumブラウザにChrome Web StoreのReadiumを追加しただけでは、少なくとも日本語組版については不完全だということなのだろう。）

EInkディスプレイのドライバソースも出ているし、指の検知は縦横にずらりと並んだ赤外線LEDとフォトトランジスタだけなので、そりゃNetBSDの移植も即座に出てくるわなぁ、と思った次第。@h_kenkenさんがんばれ。ああ、なんと動機はMikutterの組み込みですか...なるほど。

と、どうやらTogetterに着々と解析結果が集積されているようで、僕がぐだぐだ書く必要性が感じられなくなってきたので、以下リンクのみ。

• Ocher氏による代替ebook readerプロジェクト（まだ構想中。しかも海外の人）

MacPortsのqt4-macをMountain Lionでコンパイルする

山獅子について、Xcode 4.4にバージョンが上がったこともあり、いろいろと不安はあったが、特にこれといって大きな問題はなかった。

しかし、Qtについてはこれまで避けてきたのであまり困っていなかったのだが、フリーのノンリニアビデオ編集ソフトウェアKdenliveを入れるにあたってqt4-macを入れる必要が生じ、格闘することとなった。

まず、最新版のQt libraries 4.8.2が山獅子に対応していない。単純なところでは、OSのバージョンチェックに引っかかるのであれもこれもコンパイルが通らない。

これは、src/corelib/global/qglobal.hに書かれているバージョンチェックをごまかしてやればよい。とりあえず、まっさらなところで手を入れたいので、先に

  $ port patch qt4-mac

で、ソースの展開とパッチ当てまでやっておく。

そのあと編集するわけだが、具体的には、以下のようにMAC_OS_X_VERSION_10_7の定義をしているところに続いて10_8を作ってやる。

#  if !defined(MAC_OS_X_VERSION_10_8)
#       define MAC_OS_X_VERSION_10_8 MAC_OS_X_VERSION_10_7 + 1
#  endif
#  if (MAC_OS_X_VERSION_MAX_ALLOWED > MAC_OS_X_VERSION_10_8)

最後の行は、もとは10_7だったのを8に変えた。

これでcorelibのコンパイルは進むのだが、途中でファイルシステムがらみのところでdeprecateの警告が出る。おそらく、SandBox対応あたりではないかと思うが、とりあえず無視しておく。

しかし、最後にライブラリをリンクするところで未定義シンボルのエラーが出る。これは、Bug Trac Ticket 35313にあるように、いったんport configure qt4-macでMakefileまで作ってから、このMakefileのLIBSの末尾に「-framework Foundation」を追記してやればよい。

あと、WebKitの山獅子版が出ているらしいので、同じTicketのリンクにあるように、src/3rdparty/webkit/source/WebKit/qt/QtWebKit.proを置き換えるのと、山獅子用のWebKitライブラリを、同じディレクトリにダウンロードして入れてやる。

これで、コンパイルは通るようだ。

しかし巨大なフレームワークだなぁ。長大なコンパイル時間がかかる。

あとひとつ気になるのだが、いつのまにやらOpenVGが紛れ込んでいて（/opt/local/include/VG）、でもqt4-macのconfigure時にコンパイルができずに、「OpenVGを使わないQt4」ができたようだ。OpenVGのサポートはX11R7.5からということなのだが、XQuartzに入っているわけでもなく、よくわからない。

Readabilityが便利すぎる

Webサイトの記事を読むときに、余計な広告やブログパーツ的なものを全部外してくれるMobilizerサービスとして、Instapaperがよく使われていると思うのだけれども、このほど、外部サイトのみ無料になった「Readability」が、とても素晴らしい変換結果を表示してくれて、とても満足している。

行間など、レイアウトも一段上のレベルにあると思うのだが、特に、埋め込み動画がそのまま残る点が非常によろしい。かつては有料サービスで、収益を登録サイト側に返すことでビジネスをしてきた経緯があるので、有料ということで敬遠してきた向きの方には、ぜひ一度お試しいただきたいと思う次第。

モバイルアプリでは、やはりReederが従来からReadabilityと統合されているので、いままで押していなかった、ソファーのアイコンを勇気を持ってタップしていただくことを望む次第。

PC上では、Readabilityのサイトにブラウザの機能拡張が掲載されているので、導入をおすすめしたい。いわゆる「あとで読む」系のサービスも含まれていて、アカウント登録すれば、そのまま使えるうえ、「Read Now」すれば、表示されているページがすぐに変換されて表示される。

こういってはなんだけれども、技評のサイトが、記事の幅がえらく狭くて画面のほとんどを記事以外のごちゃごちゃしたもので埋め尽くされてたいへん読みにくいと思っていたので、Readabilityで非常にすっきりと読むことができてありがたいと思っている次第。

Kobo Touch (Rakuten-Version): The First Impression

Today, the Kobo-Rakuten released a Japanese version of Kobo Touch all over Japan.  I was pre-ordered it in Rakuten shopping site, so the product reaches to my hand this afternoon, when the time of starting Japanese Kobo site at 15:00 JST (UTC+9).

The Kobo Touch Japanese edition is different in global model for several specs.

1. The reader firmware is full support of EPUB3, so Japanese vertical typesetting is fully available.  This is the most important point of Japanese book lover.  We Japanese book lover have long familiar with vertically type-set texts for reading.
2. The UI is conformed to Japanese.  Such as setting menus, prompting texts, etc.
3. High quality Japanese font created by professional font maker - Morisawa is included.  The pre-installed font design is only one, Mincho as serif, and Gothic as sans-serif.
4. The biggest disadvantage: the processor (MCU) is slightly poor.  The graphics performance is inferior to global model.  I cannot understand this modification because rendering Japanese font should be graphically heavy load.  But, this decision must be the latter reason.
5. The price is awesome!  The price is only 7,980JPY (about 99USD).  I know people living in the US can buy price-off Kobo Touch at BestBuy and Walmart.  But, Rakuten released Japanese Kobo Touch in the same challenging price in every seller, such as shopping malls and bookstores.

I knew Kobo Touch's marvelous usability and availability by touching experience of global model and iOS App before, then I was expected reproducing this marvelous experience also in the Japanese edition.

My expecting is mostly came true.  I'm satisfying this product.  But, as predicted before, the response of the device is sometimes too slow as I misunderstand the device became a brick.  This might be a trade-off between the challenging price and the graphics performance of the MCU inside of this device.

At the last words, I would like to say some claims to Rakuten.

• The Kobo site (www.kobo.com) is redirected to Rakuten's Japanese bookstore site (rakuten.kobobooks.com) by using geographical IP address database.  I had been a member of original Canadian site and would like to continue using there.  Then, I had to overcome by using an open VPN site in the US instead of connecting directly from Japan.  This is very stressful and inconvenient.
• Kobo App for desktop is also connect to Rakuten site and there's no way for login to the original site.  The App should be enter my Rakuten ID for authorizing the App.  As a result of this change, I became to get my purchased books at the original site from the Web browser via VPN connection.
• The customer call service is smoothly catch the line, but the staff does not enough know-how or what's going on inside the company.  Because Rakuten is rapidly growing company, every service is always ad-hoc.  The opening of the fresh bookstore looks a rush job.  At the time of opening 15:00 JST, the site was not finished.  The site was open, but the book line-ups and categories are seen dynamically changing time to time.

 Anyway, I would recommend this device to Japanese book lovers those who are interesting to digital books because the original *freedom to the user* concept is still remain and optional Japanese support looks quite good.

MacOS Xでls -lのパーミッションの末尾の"+"文字とは

TimeMachineにバックアップされているファイルを、ディスクをマウントして単純にコピーするといろいろ問題があるようだ。

そのひとつが、自分のディレクトリであって、しかも書き込み権限があるにも関わらず書き込みができないということ。

こうしたディレクトリや、内部に保存されているファイルを"ls -l"すると、

-rwxr-xr-x+

などのように、8番目のところに"+"がついていることが多い。場合によっては"@"になっているかもしれない。

"@"については、いろいろブログに書かれていて、Apple Double時代のリソースフォークに相当する内容がついているということで、xattrコマンドで削除できると書かれている。

TimeMachineの場合は、"ls -l@"オプションで見ると、以下のものがつくようだ。

com.apple.backup.SnapshotNumber
com.apple.backup.SnapshotVersion
com.apple.backupd.SnapshotStartDate
com.apple.backupd.SnapshotState
com.apple.backupd.SnapshotType

これを手元に直接コピーした場合には、僕の場合、以下の2つがついていた。

com.apple.metadata:_kTimeMachineOldestSnapshot
com.apple.metadata:_kTimeMachineNewestSnapshot

それぞれ、

$ xattr -dr com.appple.metadata:_kTimeMachineOldestSnapshot
$ xattr -dr com.appple.metadata:_kTimeMachineNewestSnapshot

とすることで外すことができる。しかし、それらを外したとしてもこんどは"@"が"+"に化けることになると思う。

この"+"は、わかりにくいのだがlsのマニュアルをよく読むと、アクセス制御リスト(ACL)がついていることを示すのだそうだ。"ls -le"すると、 ACLの内容が表示される。例えば、

0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown

といったように、細かな設定がつけられていることがわかる。どうも、WindowsのNTFS相当のACLという説明が一般的なようだ。

ではこれをどう操作するか、ということになるとよくわからない。しかたがないので、Appleのテクニカルサポートに電話して問い合わせることにした。

最初に応対された方ではだめで、シニアアシスタントという肩書きの方に交代されたところで、関係するフォルダのFinderの「情報を見る」から、「共有とアクセス権」のいちばん右下の錠前を開いて（パスワード入力）、自分が読み書き権限があることを確かめ（いったん変更して戻すといいかもしれない）たあと、歯車アイコンのメニューで「内包する項目に適用」としてやると、フォルダ以下一括でACLを更新してくれるようだ。

電話ではこれでこちらの希望する用件が解決してしまったのでそこまでとしたが、コマンドラインがわからないのが納得いかないので調べてみた。

man aclすると、どうやらこのACLはPOSIX共通のものらしいということがわかる。そこから、See Alsoをみると、(1)としては、lsとchmodが書かれている。そこで、man chmodすると、ACLの操作もできると書かれていた。

chmodのマニュアルでは、項目を立てて「ACL MANIPULATION OPTIONS」として詳しく書かれている。ACLに指定できる項目の一覧と、操作のために指定するオプションからなる。要は、さきほどFinderの「情報を見る」のアクセス権の部分に相当することのようだ。ひとつ特記しておくなら、全部削除は"-N"オプションといったところだろうか。

DropboxやSkyDriveなど、クラウドと同期するディレクトリにも「書き込みのみ」などがついていたりする。したがって、同期するディレクトリを変えるつもりで中途半端な設定をしないよう、拡張属性やACLなどにも配慮する必要があるだろうと思う。正直な話、僕がはまったのもそれだからだ。

なお、Finderで隠し属性になっているフォルダ（ディレクトリ）を表示させるための説明として、コマンドラインで

$ chflags nohidden ディレクトリ名

とする、という説明がよくあるが、このhiddenがいわゆる拡張属性（extended property）だ。"ls -lO"（大文字のオー）すると、グループとサイズの間に現れる。ついていない場合には"-"となる。例えば/etcの下でこれをやると、"compressed"がついているものが意外に多いことに気づくかもしれない。

拡張属性については、Finderの「情報を見る」では、「一般情報」の下のほうに「共有ファイル」とか「ロック」とか「ひな形」などのチェックボックスがあると思うが、そのへんで操作できると思っていいのではないかと思う。

QUCSのバイナリインストールでエラーなく動かす

前回のエントリは、MacPortsと混在した場合にQUCSでデジタルシミュレーションを行う際のごたごたを書いた。

MacPortsを使っていない場合は、バイナリインストールをしたあと、2箇所の修正で済むことを確認したので報告する。

まず、QUCS本体のバイナリは、先のエントリにもリンクしたが、こちら。QUCSをLion環境でビルドするのはかなりしんどそうなので、これを利用するのが賢明だと思う。

デジタルシミュレーションするためのVHDLコンパイル環境、FreeHDLのバイナリはこちら。なお、このバイナリは10.5（Leopard）環境でコンパイルされているので、32bitバイナリだ。

Lionは完全64bitに移行しているので、g++も特に指定しなければx86_64アーキテクチャとしてコンパイルしてしまう。しかし、FreeHDLのバイナリがi386アーキテクチャでコンパイルされているのでリンクできない。

そこで、FreeHDLのコンパイルがi386であることを明示しておく。これは、

/usr/local/lib/pkgconfig/freehdl.pc

に書かれている。これを編集して、9行目の

cxxflags=-g -O2

となっているところを、

cxxflags=-g -O2 -arch i386

と追記する。これで、QUCSが自動生成するVHDLファイルから作られるC++ソースがi386でコンパイルされるので、FreeHDLのライブラリとリンクできるようになる。

ただし、リンクの際にGNU libtoolが「tagを指定しろ」といってエラーを出してくるはずなので、

/usr/local/bin/qucsdigi

の85行目

$LIBTOOL --quiet --mode=link $CXX $NAME._main_.o $NAME.o $LIBS $IEEELIBS -o $NAME

を、

$LIBTOOL --quiet --mode=link --tag=CXX $CXX -arch i386 $NAME._main_.o $NAME.o $LIBS $IEEELIBS -o $NAME

のように、--tag=CXXとしてg++だということとi386でリンクすることを明示してやればエラーは出なくなり、シミュレーションは完了するはずだ。

なお、GNU libtoolが使われているので、単にXcodeを入れているだけではQUCSは使えない。少なくともGNU libtoolとGuileが/usr/local/binにインストールされている必要がある。簡単なのは、Homebrewで

$ brew install libtool guile

とやっておくことではないかと思う。なお、Homebrewでは/usr/local以下はroot権限ではなくなるので、QUCSとFreeHDLがroot権限でインストールするのとは違ってしまう。例えば、これらをインストールしたあと、

$ sudo chown -R 自分のユーザ名 /usr/local

などとしておくと、上のファイル書き換えもsudoする必要がなく、楽なのではないかと思う。

ついでに、デジタルシミュレーションはFreeHDLに完全に渡してしまい、QUCSは実行結果をビジュアライズするだけなので、QUCSがどのようにコンパイルされているかとは無関係だ。 最新版のFreeHDL 0.0.8のソースは、現在sourceforge上にある。これをダウンロードして、単純に./configure && make installすれば、x86_64でライブラリがコンパイルされるので、freehdl.pcの編集は不要となるし、qucsdigiでも-arch i386の記述は不要にある。コマンドラインに慣れている人は、こちらのほうが簡単でいいかもしれない。

さらに、QUCSはデジタルシミュレーションの際にVHDLとVerilogを選択できるようになっているが、Verilogコンパイラとして期待されているのはIcarus Verilogだ。しかし、これはMacPortsでもHomebrewでもコンパイルが通らない。ところが、上記ページで示されているGitリポジトリからheadをとってきたところ、難なくコンパイルが通り、QUCSでも動いた。関心のある向きは試してみてもよいと思う。なお、bisonを使うので、予めbisonのインストールをしておくことと、autogenしなければならないので、autoconf, autogen, automakeも入れておくことをお忘れなく。

QUCS難しい

回路シミュレータというものに慣れていないということを措くとして、いまひとつ直感的に示すことができなかったという反省がある。

いきなり授業でQUCSを使わせてみたのだが、実際に回路を組んで測定するのと較べてどのぐらいわかりやすかったか、というところに課題が残った。

ただ、優秀な学生がいろいろと発見してくれて手助けしてくれたので、学ぶことは多かった（それでいいのかという問題はあるけれども）。

難しい印象を受けるのは、結果が表や図の形でしか示すことができないこと。iOS版のiCircuitというアプリは電流をダッシュラインの移動で表したり、LEDが光るような表示の変化があったり、スイッチをタップで操作できたりと動きがあるのだが、QUCSはあくまで静的なので、実物を見る（といっても配線に手こずることは目に見えているのでどちらが楽かという判断はできないのだが）のとは違うという点で期待を裏切ってしまう。思考して図や表から動きを想像できる受講者（現職教員の受講者など）はそれなりに感動していたので、訓練の問題といえるかもしれない。

今回はWindowsで動かしてみたのだが、MinGWを要求する時点でやや強引な移植という印象を受けた。一方で、MacではQt3に依存しているためコンパイルが通らないなど、それはそれで問題がある。MacPortsにqucsは入っているけれどもi386バイナリを前提とするようで、現状、依存関係にあるひとつが+universalでなく、コンパイルエラーになる。

だが、プロジェクトサイトのnewsを見ていたら、最新ではないがMac版のバイナリ配布があったのでここに引用しておく。

デジタル回路解析に必要なFreeHDLはこちら。0.0.7で、事実上の最新（ソースコードのページには0.0.8のリンクがあるが、その先は404になるので引っ込められているような気がする）。QUCS本体は0.0.15でひとつ前のバージョンだがこちら。Qtもbundleに含まれているようだ。ソースレベルではqt4対応ブランチがあるがコンパイルが通らなかった。日本語フォントは、Windowsの場合、名前の末尾に「UI」がつくものにしないとメトリックがオーバーフローしてひどいめにあうのだが、Mac版は大丈夫なようだ。とりあえずIPAフォントでだいたい問題なく表示されている（ベースラインがやや高いような気がするが）。

ただし、GNUのlibtoolに依存したビルド環境なので、FreeHDLの設定がMacPortsとコンフリクトする。QUCSの一部もコンフリクトする。いずれもシェルスクリプトなので、絶対パスを指定するとか環境変数を内部で設定するとか、個別にlibtoolを呼び出すとか、デジタルシミュレーションを実行する際のVHDLコンパイルが成功するまでには各所の手直しが必要（エラーダイアログに行番号が出るので、そこを手当てする）。また、Guileを呼び出すSchemeで書かれたコードも存在するのでGuileのインストールも必要。Guileを呼び出す部分も絶対パスに直してやる。と、いろいろやるのだが結局、pkg-configがMacPortsと衝突するので、FreeHDL 0.0.7のtarballをとってきて、普通に./configure --prefix=/opt/local して自分でmake installしたものに手を入れるのが手っ取り早いと思う。

このあたり、いろんな意味でLinux前提の結構やっつけコードという印象がないでもない。

（追記2012/06/18：MacPortsを入れていない場合はバイナリインストールから簡単に行ける。次のエントリ参照）

一応FreeHDLまで連携できてデジタル回路のシミュレーションができたので画像を載せる。単なるAND回路なのだけれど、出力先をどう処理するのがいいのかわからないので、適当に分周回路につないでおいた（受動素子を入れるとシミュレータが動かないので）。

i1が下の位、i2が上の位、o1が出力

一応AND演算になっている

Kinect Works!

My Kinect boutght at a Junk-Shop by under $5.00 works on the Kinect for Windows SDK!!

Junk Kinect that working, with price tag 500JPY :)

This Kinect is for Xbox360 and the connector was special, then I broke the connector and solder lines with another junk USB cable and a power connector for DC12V AC-adapter.

The scheme of the connection between the Kinect and other cables were very easy because the color of the Kinect's lines for USB connection was the same as the other USB cables, and the rest one line was for DC12V power supply.

Junction part on my cable

All the sensors work now on my Windows 8 Release Preview Mac.  Perfect! :)

All sensors are appear on Device Manager!

Depth Image!

----
500円で買ったKinectうごきました:)  Xbox360用なのでコネクタが特殊だったのだけれど、丁寧に壊して（コネクタ内部はグルーガンで使う樹脂で充填されていたのが意外）、配線をUSBとDC12Vにつなぐのだけれど、別にジャンクで買った50円のUSBケーブルを切って現れた線の色とKinectの線の色が同じだったので、

赤-赤（Vcc）
緑-緑（D+）
白-白（D-）
黒-黒（GND）

とつなぐだけでOKでした。残りはDC12Vのほうなのですが、残った茶色が+12V、そしてGNDを黒のところにつなげばOK。ついでにシールドどうしも接続して、小さなプラケースに収めました。

そして、Kinect for Windows SDKとToolkitをダウンロード、インストールした後、Toolkitに入っていたサンプルを動かしたら、きれいに映像もとれ、深度画像も得られ、ボーン（骨人間）画像もリアルタイムにキャプチャできました。音声はまだ試していないのですが、たぶん大丈夫でしょう。Windows版のSDKはバージョン1.5なので、近距離モードや上半身モード、顔認識にも対応していて、なかなか満足です。

さて、これをネタに活用を考えなくては...

Mac mini (Mid 2011)にHDDを追加する

以前の投稿で、先月届いたMac mini（おそらくMid 2011モデル）にはHDDマウンタがないと書きましたが、実はちゃんと入っていました。

ひっくり返して蓋を外すと内部にアクセスできる構造ですが、最初にHDDが入っていたのが底面に近いほう、つまり、蓋をあけた状態で上側ですが、ここは2mm程度の頭がついたボルトを筐体側、つまり外側の穴に引っ掛けた状態で固定することになっていました。で、その下、つまり天面側（2台目がはいるところ）には、覗きこむと直径1cmぐらいの穴が外側にも内側にも合計4つあります。これが、2台目のHDDを固定する穴だったのです。

で、BTOで2台入っているわけではない場合は、例のSATAコネクタをロジックボードの約1cm角の表面実装コネクタに接続する特殊ケーブル（フレキシブルケーブルとコネクタのセット）が必要なのですが、ひと通り探してみたところ、結局Vintage Computerさんの「Mac mini Mid 2011 HDD/SSD増設キット」しかありません。eBayも探してみましたが、おそらく同社がUS国内向けに出したものの転売と思われるものしかなく、そっちのほうが高いので、VC社さんに直接注文させていただきました。

VC社さんですが、この手のApple正規ディーラーでも入手が難しそうなもののほか、Old Macの交換部品など、かゆいところに手が届く品揃えを用意していて、また社長ブログも、堅苦しくはないのですがそれなりにビジネスを弁えた製品調達のエピソードや新商品の紹介などで、好印象を持ちました。ご存じない方のために、社長は日本人です。おそらく移住された方が起業されたのだと思われます。

この品物は、僕にとってはあまりにも高価な買い物ではありましたが、決済はPayPalでできますし、時差もありますからわりとすぐに発送していただいて、LAXから日本に日通の国際宅配便で、4-5 business daysぐらいで届きました。実に迅速です。おすすめしておきます。

さて、届いた品物は天面側HDD用特殊ケーブルと、ポリエチレンのキャップ（これが直径1cmぐらいで、ベゼルの穴にはまる）がついた、2mmぐらいのボルト4本のみです。要するに、これらを取り付けてはめこんでくださいね、ということなのですが、これはちょっとしたパズルでした。

まず、固定用のボルトをつけた状態で、ケースで一部が隠れている隙間にHDDを入れ、ベゼルに収めるというのは相当に難しいです。

しかたがないので、キャップだけベゼルにはめて、ボルトなしでHDDをさしこもうとするのですが、これもなかなか入らない。特殊ケーブルがあるので、それをちぎらないよう注意してなんとかもがくのですが、ふとした拍子に入ってしまいました。すると今度は逆に出せなくなってあせるわけですが。コツらしきところは、思い切ってコネクタ側を奥に押しこむような動作をさせつつ、HDDの反対側を右向きに回転させるようにねじ込むような動きで入るようです。

このあと、もとあったSSDを上に入れるわけですが、このときにはベゼルの穴の位置をよく確認して、きっちりと入れなければなりません。ただ、やってみて気づいたのですが、HDD側のケーブルの長さが足りないような雰囲気で、コネクタがロジックボードに合わなくなります。なので、さらに奥に押しこむことでケーブルの長さを稼ぐ必要があるようです。そうしないと、SSDを入れてからではフレキシブルケーブルを強引に引っ張ってHDDを移動させることになり、かなり怖いです。

最終的になんとか蓋ができそうな状態に持ち込むことができましたが、それでも下から上がってきているフレキシブルケーブルが少し歪んだ状態になってしまいました。もし、これから試す人は手順をよく考えながら位置決めをしたほうがいいと思います。さらに僕の場合、Wi-Fiのアンテナがついたアルミ蓋がSSDを固定するネジ位置に、フレキシブルケーブルがちょうど重なってしまい、一方のネジ止めができない結果になってしまいました。逆に、前回留められなかったネジは、SSDが正しい位置に固定できたためでしょう、ネジ穴は合っていました。

というわけで、240GB SSD + 500GB HDDという構成ができました。これでThunderboltから昔のビデオテープをキャプチャして保存することができる見通しが立ちました。

Windows 8 Release Previewへのアップグレードは何も引き継がない

きょうWindows 8 Release Previewが出て、早速アップグレードしたのですが、「何も引き継がない」しか選べなくて、どういうことかと思ったら、PCの名前やユーザ登録から全部やり直しという結果でした。

特にあせるのが、ホームディレクトリ下にあったファイル群やらインストールしたプログラムなどが全部消滅することではないかと思います。

でも安心してください。C:\Windows.oldの下に、以前の環境は全部残っています。

たぶん最初に登録するユーザは管理者権限があるでしょうから、エクスプローラーで移動するだけでファイルは取り戻せます。

一方、アプリケーションはすべて再インストールしたほうがいいと思います。ざっと見て、どうも見た目ではわかりにくいいろいろなところに変更が入っているようなので、そうでなくてもレジストリエントリなど引き継ぎが難しいものがありますから、諦めてやり直すのが無難という結論です。

ひとまず速報でした。

Mac mini (Early 2009)に3.5inch HDDを接続

もう一台のほうは、Windowsでなければならない仕事（一太郎の書類とか、授業の準備でWindows版の操作を確認するなど）に使うマシンの更新となります。

いままで使っていたのは10年前に買ったPentium 4のミニタワー。メモリ増設したりHDDを入れ替えて1TBのやつを3本にしたりと、だましだまし使ってきたものです。問題は、WindowsをXPから順にアップグレードしてきたことで、なんだかよくわからない状態になっていること。そこで、速度に不満はないけれども省電力ということも考えて、このマシンは引退させることにしました。

いくら2009年モデルとはいえ、Mac miniはCore 2 Duoですしメモリも4GB載ってます。残念なのはプロセッサが64bit対応していないため、4GBがWindowsでは使い切れないというところだけです。

あと問題は、3本の1TBドライブ。Mac miniに3.5inch HDDを接続するネタはネットの定番みたいでいろいろあるのですが、内蔵HDDを抜いて「SATAの延長ケーブル」というやや入手が難しいケーブルを使って本体の外にケーブルを出し、そこに別電源を用意した3.5inch HDDを接続するというやりかたです。出せるSATAケーブルは1本なので、1台のHDDしか接続できません。USB端子は空いていますがUSB 2.0の速度では仕事になりません。

そこでやむなく、いつもの私費投入（1TB×3も私費だった）で、いま急に安くなっているという2TBのHDDにまとめることにしました。

実際やってみると、まとめた分中途半端な空きがなくなり、余裕で全データを移行することができました。

とりあえずMac miniに空の2TB HDDを接続してWindows 8 Consumer Previewをクリーンインストールしました。この手順は前回と同じ。そのあとは、すでにWindows 8になっているミニタワーのデータを移動することです。このとき、ファイル共有でやったらどうかという話もありますが、たしかに両方とも1000Mbpsのインタフェースを持っていて、どちらもギガスイッチにつながっているので速度的には問題がなかったかもしれません。でも、なにかのはずみで速度低下を起こすとWindowsのファイル共有は急激に遅くなって、以後どうしようもなくなる経験を何度もしてきたので、同一マシン内でファイルの移動をすることにしました。

結局、新しい2TB HDDを起動用でない1TB HDDのどちらかと入れ替えてコピーを2回繰り返し、最後に起動ドライブのデータを移しました。SATAですので150MB/sですが、USB 2.0の最大480Mbpsつまり高々50MB/sと比べれば3倍以上の速度です。TB単位の移動ですが、1日でなんとかなりました。それより廃棄する（実際は私物なので中古に出すのですが）ためのデータ消去に二晩かかりました。

で、ちとユーザプロファイルの問題などでMac miniに戻したときに「書いたはずのデータが全く見えない！」などという怖いことが起きましたが、復元や再起動などを繰り返して無事すべて見えるようになりました。ディスクはむきだしのままですが、いまのところ熱の問題はなさそうな感じですし、いずれ基板保護のゴムシートでも貼ってやろうかというところです。

Mac mini (Early 2009)にWindows 8 Consumer Previewをクリーンインストール

2台あったMac mini (Early 2009)のうち、1台は特に手を加えずにWindowsマシンとして使うことにしました。

こちらは300GBのHDDが入っていて、Core 2 Duoではあるので、動画エンコード専用マシンにはちょうどいいかなという考え方です。いまは同じく2009年モデルのMacBookのbootcampでやってるのですが、ノートPCでCPUぶんまわし続けるのはちょっとかわいそうな感じがしてきまして。

で、Windows 8ですから当然Bootcamp 4.0のドライバが必要です。幸いLionが入っているので、「Bootcampアシスタント」でドライバ一式が入ったUSB Stick（CDでもいいとのことだけれど、OSのインストール後に入れ替えるのに不安を覚えたのでこうしました）を作れば準備完了。

で、このマシンでMac OSを使うことは金輪際ないので、クリーンインストールをしたいと考えました。で、たしかWindowsはパーティションやフォーマットもインストールDVDからできたはずだと考えて、やってみたわけです。

ところが、インストールDVDは、Mac OS Xのジャーナリングファイルシステムを知らないらしく、またパーティションデータを格納する領域もWindowsとは違うらしく、パーティションを消すことはできてもそこからパーティションを作ることができず、「だめだこりゃ」ということになりました。

Lionが生きている間だったら、そちらの「ディスクユーティリティ」でFAT32にフォーマットすることはできますが、パーティションを消してしまったのでそれもできません。で、昔Lionが出たときにネットの情報にしたがって作ったDVDからbootすることもできませんでした。これは先述した通り。で、最初からLionが入っているマシンなら「Internet Recovery」もできたのですが、このマシンはSnow Leopardの時代なのでそれもかなわず。

で、じゃあSnow LeopardのDVDでディスクユーティリティ起動して、そのままOS入れずに再起動すればいいじゃんと思ってやってみたところ首尾よく成功。

ちなみにFAT32はWindows 98とかMeとかの時代の話で、2000以後はNTFSです。でも、Windows 8のインストーラは一瞬文句を言いますが、そのまま勝手にFAT32からNTFSへフォーマットしなおしてくれて、さくっとインストールが完了しました。もちろん、デバイスドライバの入ったUSB Stickは端子に挿しておいたので、必要なドライバも全部入っていて、再起動したら何の問題もなく金魚の画面が出て起動してくれました。2009年モデルはキーボードもマウスもboot時にUSB接続していないと起動しないので、Windows 8側でも標準ドライバで問題なく動きました。

ひとつ問題になったのは、スロットインのDVDドライブなので、ディスクの強制排出手段がソフトウェアでやるしかないこと。これは、Windows 8になればエクスプローラーから排出操作できるのですが、インストール途中にSnow Leopardを抜くときに問題になります。

で、解決は、再起動している間に、Apple純正キーボードのディスク排出ボタン[▲]を押し続けること、でした。このMac miniを買ったときにいっしょに買ったキーボードがあって助かりました。Windows側ではWindowsキーが、まぁコマンドキーを使えばいいのですが、スタート画面に戻るキーだったりするので、780円で偶然見つかったUS配列のUSBキーボードにしておきました。

あと、まさかいまだに存在するとは思わなかったのですが、大須のあるショップに処分品でPS/2のキーボードとマウスをUSB端子に接続するアダプタが480円で出ていたので、ずっと眠っていた初代Happy Hacking Keyboardを復活させることも考えています。

Mac mini (Mid 2011)で空のSSDからLionをインストールする

Mac mini (A1347)が納品された。これを買うのはThunderbolt DisplayとつながるMacが手持ちのAirしかなかったから、ということなのだがそれはそれとして。

せっかくなので、内蔵ハードディスクはおまけと考えて、SSDメインで使うことを考えた。ただし予算がないので240GB。結局セカンドディスクは必要ということが判明。

箱から出して、電源を入れる前にまず分解（お約束）。検索キーワードで「Mac mini 分解」とか入れればいろいろ丁寧な説明のあるサイトがあるので参照。

それなりの特殊ドライバーセットがあれば、分解はたいしたことはない。しかし、大問題があることに気がついた。

いくらAppleだからといって、特殊なコネクタをわざわざ内部で使うことはないでしょうと高をくくっていたのが大間違い。SATAのコネクタは、マザーボード側は1cm角程度の表面実装コネクタ。
2.5inchドライブとは、特殊なコネクタで接続することになる。今回はHDD 1台のみで発注しているので、内蔵500GB HDDにそれがついている。

サイトによっては、「上位モデルのMac miniでは2台目の増設ができるようにマウンタも入っている」などという記述があったけれども、実はこのMac mini、上位モデルにもかかわらず、そんなものは入っていなかった。

よって、500GB HDDを外して240GBのSSDと置き換えるほか手はない。ただ、まぁ製造元の中国工場からの横流し品かもしれないけれど、増設用マウンタと特殊コネクタのセットは販売されている。IT系ニュースサイトでも記事になっているので検索して確かめていただきたい。国内価格では、4980円。それが秋葉館では6300円。たぶん同じものだろう（途中経路は違うかもしれないけど）から、お好きなほうでどうぞという感じ。
もちろん、正規修理代理店に在庫があればごにょごにょする方法もないわけではないだろうが、きいた話では、「高いよ」とのことだった。なんでも、Appleは正規修理代理店にも部品では卸さず、故障品との交換を証明できなければ品物を出してくれないとのこと。昔、SONYショップからいろいろと保守用部品を取り寄せて自分で交換していたものだが、Appleは世知辛いよのうと思った次第。SONYの偉かったことは、交換部品（故障部分）を必ず添付して返却してくれること。不要ならその場で引取りにも応じてくれるが、自分で故障原因を調べるとか、部品とりに使うとか、コレクションするとか、すりすりするとか自由にしてよいということで、「お客様がご購入されたものはお客様のものです」という商売の基本を示していると感じたものだった。

とりあえず秋葉原まで6300円握りしめて出かけるようなところに住んでいるわけでもないので、そのうちどこかから通販で入手するとして、SSDに換装した状態でふたを閉めた。ただし、オリジナルのHDDとねじ穴が若干ずれていたせいか、ひとつだけどうしても止められないねじがあった。ちなみにSSDは、OCZのAgility 3の240GBモデル。なぜこれかというと単に店に置いてあったものでいちばん安かったから。Appleが新製品を発表すると1時間以内に完全分解写真を提供する名物サイトiFixitが扱っているのは、偶然同じOCZのAgility 3の120GBモデルだった。もしかすると、120GBであればぴったりサイズなのかもしれない。

で、論理フォーマットさえ定かでないSSDからLionをどうやって入れるか。普通の人は、「LionにアップグレードするときのイメージファイルをDVDに焼いた“インストールディスク”があるじゃないか」と考えるだろう。あるいは、Snow LeopardのCDでいったんクリーンインストールしてからMac App StoreでLionにアップグレードする人もいるだろう。僕は前者の考えだったのだが、どうにもインストールできない。
普通なら、「Cを押しながら電源を入れる」という伝統的なやりかたで強制的に光学ディスクからbootさせようとするだろう。ところが、なにもしないで起動しても、フォルダに「？」がついた絵が点滅するのみ。Cを押すと、通行止マークがしばらく出て電源が落ちてしまう。

なお、この状態ではThunderbolt Displayをつないでも電源は入らない。あくまでLionが起動していることが前提のようだ。本体と同梱された「HDMI-DVI変換ドングル」を利用して、DVI端子をもったディスプレイを接続しなければならない。また、念のため、キーボードもマウスもBluetoothではなく、有線のものをつないでおいた。

さて、こういうときにどうやってLionのインストーラを起動するか。ここでようやく、Lionから導入された「Internet Recovery」が活躍する場面になる。ちょいと検索してみたら、ややわかりにくかったが、「Optionキーを押しながら電源を入れる」のだそうだ。そのときの画像が以下のもの。

まずWi-Fiを検索しようとする。ここでWi-Fiスポットに接続してもよいが、有線LANを接続してほっておいても、いずれ右の画面に移る。ここで「↑」をクリックすればインストーラがダウンロードされる。その画面が次のもの。

ネットワークの速度によるだろうが、10分ほどもすると、おなじみMax OS Xのインストール画面になる。

ただし、Lionのインストールに入っても、SSDがMac OS Xの論理フォーマットになっていないので、インストール先のディスクが現れず先に進めなくなる。まず、「ディスクユーティリティ」を選択して、SSD全体をひとつのパーティションに設定しておく（パーティション分割したい人はそれなりに）必要がある。そうすれば、あらためてLionをインストールする段になって、ちゃんとフォーマットしたディスクドライブが現れる。

Internet Recoveryでは、LionもAppleからダウンロードされる。ざっと1時間程度でインストールは完了した。

ここまでくれば、Thunderbolt Displayをつなげばすぐに認識され、電源が入る。あとは「移行アシスタント」などで環境を移すなど、いつもの手順を進めていけばいい。

なお、本日現在の最新はLion 10.7.4のはずだが、Internet Recoveryでは、「ソフトウェア　アップデート」を実行してみたところ、AirMacアシスタントとかいくつかのアップデートとともに、10.7.4のアップデートも現れた。雰囲気としては、1週間ぐらい前のイメージだ（なぜか、Safari 5.1.7は現れなかった。あとでもう一度確かめなくてはならない）。

現在「移行アシスタント」実行中なのだが、もとのMac mini (Early 2009)が遅いからだろうか、いまのところ3時間以上の残り時間を表示しつつ、時間は伸びていく一方だ。このまま静観したい（社説の終わり方風）。

[Book Review] "Getting Started with RFID" by Tom Igoe; O'Reilly Media

Forward

I would like to recommend people who would like to know how the RFID works and how to built in your some electrical projects.  This book, "Getting Started with RFID" is very concise, easy to read, and includes very practical description of wiring, programing, and controlling devices.

Related Books

The author excuses this is an excerpt from the previous version (1st revision) of famous book "Getting Things Talk" from O'Reilly Media, because the current (2nd) revision replaces the article for RFID into the cutting edge technology - NFC (Near-Field Communication) which is adopted to such as Samsung's Galaxy Nexsus S, etc.

However, this book is still have a value for learners or hackers who want to implement not-so-complicated projects such as the same as familiar applications on a token of transportation systems. Yes, every IC tokens as an ticket for some countries' local trains are still not an NFC but this kind of simple RFIDs. Maybe, some leading countries in transportation systems such as England, Korea, and Japan adopt "non-contact type IC cards", but they may still be not an NFC (I am Japanese, and IC cards available in Japan nation wide is the SONY's "FeliCa" which is slightly different from NFC and it does not have compatibility with it, sigh...).

Summary

This book describes how to utilize the Parallax's RFID reader and devices with your project by using some very concrete and highly readable example programs written in Processing and Arduino.  But, because this reader only send the unique ID of each RFID device from TTL-level serial data, any programming languages that can handle serial stream are applicable. Not only this virtue, but the conscious comments on every example codes leads the readers; both novice and expert programmer convince why every specific instructions are put there as so.

Consequently, this book is a handy primer for everyone who have an interesting to utilize RFID technology.  I would recommend it.

MacBook (late 2009)にWindows 8

火・水曜とマイクロソフトのセミナーを受講して、WIndows 8は正しい方向に進んでいると思ったので、まずは職場のWindowsマシンを7 Professionalから8 Consumer Previewへと移行してみたところ、全く何の問題もなく動いてしまった。従来のアプリも一切問題なくそのまま動いた。唯一、Microsoft Security Essentialだけ、移行途中にアンインストールしなければならない（8には最初からAnti-Virusのしくみが入っている）が、それだけのことだった。

というわけで、自宅に置いてある白MacBook (late 2009)のBootcamp環境を7 Proから8にしてみた。これも同様な手順で簡単に終わったのだが、問題が残った。

まず、キーボードが日本語配列の設定だった。物理キーボードはUS配列なので、これでは困る。しかし、Windows Updateをかけると15個のアップデートがあり、再起動後には英語キーボードとして認識された。で、これは解決。

ただし、デバイスマネージャで見るとわかるが、Apple Keyboard/Touch Padはエラーになっている。しかし、輝度変更などMacのファンクションキーに配列されている機能は使えている。一方、Touh Padは動かないままだ。

BootCampのバージョン2~4まですべてのドライバを試したが、どれもだめ。ものは試しと、Multitouch Vistaを入れてみたが、コントロールパネルに「ペンとタブレット」などの項目は入るが、これといった設定はできないし、ドライバが無効なのはかわらない。

ネットで調べてみたが、仮想環境で使っている場合でも、VMとセットになるWindows向けツールは対応していないようで、こればかりはいかんともしがたいようだ。

というわけで、Touch Pad、要するにマウスについては、USB接続するしかない。BlueToothは生きているのでMagic TrackPadはどうかと思ったが、面倒なので試していない。まだ正式版ではないので、夏のRCもしく正式版が出る頃にはAppleがBootcampのバージョンを上げてくるのだろう（Mountain Lionに入ってくるかもしれない）。それまでは待ちというのが現状の結論ではないかと思う。

この際だからioBook Airについて一言いっておく

久々に自腹でなく東京出張したついでに、秋葉原へ寄ってきた。というより、秋葉原が久々なので、いろいろな意味で知らないことが多かったのだが、それはそれとして、ioBook Airである。

風のうわさで聞いたような気がしていたがすっかり忘れていたこの製品、なぜかイオシスでない別のショップ店頭にあり、遠目で見てなるほど立派な中華だと感心。そして、仕事後の秋葉ショップ閉店時間に追われるようにあちこち巡った挙句、用はないのだが念のためイオシスで確認してきた次第。

で、ネットで検索してみたのだが、実物を見ないでいろいろ言っている輩が多すぎる。また、ニュースサイトの記事も煽りすぎだ。

実物に実際にさわり、店員の正直な話を聞けばわかるのだが、あらゆる部分に「なんちゃって感」溢れまくりの製品なのだ。実際いまCupertinoでデザインされた「ほんまもん」のAirでこの記事を書いているのだが、あれは共通部品らしきところはかなり少ない。

少なくとも、アルミユニボディは、素材が違う。というより、金型が違う。図面は流用しているのだろうが、いろいろ作りかけて失敗した痕跡があるのだ。

まず右側。Mini DisplayPortとUSBはそれらしいが、その手前にmini HDMI出力があり、さらにその手前に謎の横長の穴がある。これはどうも特殊形状のコネクタで有線Etherを出したかったらしい残骸とのこと。回路設計に失敗したのか、どうにも動かないらしく、イオシス側で端子部品の実装をやめる指示を出し、コストを下げたらしい。

というわけで、虚しく内部基板を覗くだけの空気穴というか好意的にとらえれば通気口がぼんやりと空いているという状態。

次に、左側面だが、ACとUSBは普通にあるが、イヤホンジャックのあるべき場所はSDカードスロットになっている。そして、イヤホンジャックの穴はその手前となる。

で、Cupertinoで設計されたものと並べてみれば、この中華はそれだけ余計なパーツを入れたことにより、筐体が厚くなっているわけだ。

また、トラックパッドはやや小さめだ。感触も、梨地といえばきれいだが、ざっくりいうと10000番台の紙やすりのような雰囲気を覚えた。筐体も同様に、ややざらざらしている。

トラックパッドが小さくなったのは、キーボード部分に押しやられたためと考えられる。

キーボードについてなぜ誰も言わないのか不思議なのだが、キートップは8bit時代懐かしの「消しゴム」風である。四角い濃いグレーの消しゴムが3mm近くは突出していると考えてもらいたい。その上に文字が印刷というか転写されている。消しゴムそっくりの手触りと、押したときのぐにゃり感はまさに8bit機のそれである。NECならPC-6001とかMSXとか、記憶がある人は各自想像してもらいたい。そして、キートップがそんな感じなためなのか、いわゆる遊びのスペースが多くとられている。そのことで、キー間隔が広がり、全体で面積をたくさんとる結果になっている。

液晶は正直、どのぐらい違うのかわからなかった。液晶パネルは同等品がいくらでもあるので、まぁそのへんで手に入りやすいものを使っているのではないかと思う。ロットによって違っていても不思議ではない。だって中華だもの。

背面の光るイオシスのロゴをどうこう言う意見がネットでは目立つが、こうした全体の「なんちゃって」感からすれば、このロゴなど別に目立つ欠点とはいえない。ダメ押ししときました、という店長の声が聞こえそうだ（大阪本店は知らないので、本人がそう思っているかどうかはわからないけれども）。

で、動いているWindows 7だが、別段言われているほど悪くはない感触だった。

さて、なぜ僕がこれをわざわざ見に行ったかというと、Windows 8のMetro環境でスナップ表示まで手っ取り早く使えるマシンとして、4万弱ってのはまぁそこそこいけてんじゃないの、という理由に尽きる。中古のもっと安いマシンで1366x768の解像度はなかなか見当たらないし、その上でSSDかつ4GBメモリならば、そこそこ妥当な価格設定ではないか、ということだ。

そこでWindows 8について尋ねてみたのだが、「Wi-FiとBlueTooth両方をひとつにしたチップが一般的じゃないやつで、ドライバの互換性が怪しい」ということだった。Windows 7用のドライバはチップメーカーからダウンロードしてくれば動くのだが、Linuxだとどうもまともに動いてないみたい、という話。大阪方面で、動くドライバがあったとかなかったとかいう声は出ているらしい、というのが現状とのこと。

こういうマシンでWi-Fiなしはかなり厳しいところだが、「普通の100MのUSBアダプタならWindows 8でもいける…と思いますよ」ということだった。たぶん、そうなんだろう。

結局、Wi-FiもBlueToothも忘れて有線で開発用に遊ぶ「なんちゃってマシン」ならば、十分いけるというのが僕の全体評価。外で本気で使うマシンではない。だって消しゴムキーボードだもの。ごりごりコードを書くにはあまりにもストレスフルだ。

ただ、画面はおんなじ雰囲気で、まぁ高精細ではあるから、その部分ではいいかもしれない。だから、開発したアプリの動作確認には十分だと思う。

結局ある意味、Windows 8標準搭載マシンが出るまでの「つなぎ」の期間である「いま」でのみ「うまみ」がある製品ではないだろうか。8ではマウス操作はオプショナルだから、本来タッチパネル搭載が望まれるのだが、Windowsが動くタブレットはまだまだ高い。ちょっと歩いて探してみたが5万ぐらいする。そこまで払うのかどうか迷った心の隙間に忍び寄ってくるマシンだと思う。

Video.jsの簡単なつかいかた

授業でビデオを観る課題などをよく出すのだけれど、Flashには死んでほしいので、授業のMoodleではmplayerモジュールは緊急避難的に使って、普通のHTMLリソースのなかにvideo要素を手で書いて対応していました。

ところがなんだか、いったんMoodle 2.2+にして大はまりしたあげく1.9に戻ってきたら、なぜだかいままでのビデオが全く表示されなくなり、一念発起してVideo.jsを使えるように無理やりlib/weblib.phpを書き換えたりなどしました。ほんとはちゃんとモジュール開発すべきなんですが、時間がなかったもので。

というわけで、Video.jsです。

なかみはとても単純で、CSSとJavaScriptで書かれたHTML5ビデオプレーヤーに、念のためFlashにfallbackするためのswfがついているという構成。設定は、CSSをheader要素間にlink要素で入れて、あとbodyにscript要素としてJavaScript本体を読むように書くだけ。

と、これだけならオリジナルサイトに書いてあるだけのことなんだけれど、ちと大きくはまったのが字幕なので、そのことについてだけ記すことにします。

まず、字幕（ここではsubtitlesということにします）は、WebVTTを使います。まぁ、一応W3C的には標準。だけど、従来の字幕とはやや趣が違うフォーマットなので、直接これを編集できるアプリケーションは、なんかMSが出しているとかいう話ぐらいしか見当たりませんでした。

でもまぁ、なんとかなるという話を以下に。

まず、ここはやはりオープンソースなAegiSubを使うことにします。これの素晴らしいところは、音声波形ビューアで、適当に音声の切れ目らしいところを単位にして、自動的に次の字幕項目を入れられること。必ずしもきれいにいくわけではないので、多少マウス操作で調整したりはしますが、時間の数値をいじることを全くしないで字幕トラックを作れるというのがたいへんありがたいと思いました。出力形式は、SRTにしときます。なぜかというと、WebVTTとかなり近いから。

とはいえ、WebVTTのほうが表現力は高く、縦書きの字幕を表示できたり（bidiも考慮されてる）、表示位置の指定ができたりといったようなことはあります。そのへんはASSから変換できたりするといいのかもしれないのですが、まぁそれはそれ。

SRTからWebVTTを作る手順は以下のとおり。

1. SRTに入っている通し番号を削除する
2. 1行目に先頭から「WEBVTT」と書き、2行目を空白行にする
3. 表示タイムスタンプの時間表記を、ミリ秒の前の「,」を「.」に置き換える

仕様書に従えば、たったこれだけのことでOKということになります。vi使ってれば一瞬ですね。

%s/^[0-9][0-9]*$//
%s/,/./g

ところがよくわからんのですが、いまのVideo.jsは、仕様書ではオプションとして定義されているタイムスタンプの「hour」の項目があるとダメっぽいのです。hourなしでどうやって59分以上の長さの字幕を作るんだというと、60以上の数字にするんだとか。桁数については「59を超えたら60の剰余とし、商を上の位に上げる」的なことしか書いてないので99分超えても大丈夫なのかもしれないけどやってないので不明。

というわけで、残念ながらタイムスタンプから時間を消す編集が必要。こんな感じでしょうか。

%s/^00://
%s/> 00:/> /

で、まぁ、1時間以後は毎分ごとに60を足してやるみたいな感じでしょうか。もうこうなってくると、スクリプト書きたくなる感じですが、とりあえずこんなところで。

あと、オリジナル設定だと字幕は10ptベースの1.4emなので、日本語の表示にはちょっと小さすぎる感じです。2emにしたらいい感じになりました。あと、text-shadowとかお好みでタイプフェースをいじる等はやってくださいという感じです。font-familyもarial, sans-serifぐらいしか書いてないので、僕は日本語フォントを追加しておきました。ヒラギノとか。

回路シミュレータQUCS

電子回路の設計や学習に、PC上で回路の実験や測定ができる回路シミュレータは便利だ。それこそ、単純なオームの法則でもさくっと回路図を描いて抵抗値や電圧・電流などを測定できるので、年齢を問わず教材として使えるものだと思う。

業界標準ではSPICEということになっていて、一般的にはリニアテクノロジー社のLTSpiceをダウンロードして使うことになっている。LTSpiceは同社のアナログICなどのデバイスを買ってもらうために無償で配布している（専門家はもっと高級なものを購入するのだろう）。

問題は、Windows専用ということだろう。

そこで、他のOSを使う人で、GUIがほしいよという人はQUCSを使うらしい。Qt3ベースで、GUIのマルチプラットフォーム化を実現している。また、各国語の翻訳データも入っているので、日本語メニューに設定変更できるのも授業で使うにはありがたい。

念のため、2011年秋頃最終更新の0.0.16をダウンロードして入れてみた。Windows用バイナリは同じSourceForgeの別リンク先からとってくる。Macの場合は、MacPortsに入っているので、適当にパッチを流用するなどすれば手動でも入れられるだろう。それより、Qt3が巨大なフレームワークなので、MacPortsではQt3のコンパイルで一仕事になるように思う。

問題は、日本語メニューの表示だ。Windows 7の場合どうなるか、という記述はあまり検索上位に上がってこないようだ。なので、一応書いておくと、

1. Languageを「Japanese (jp)」にする
2. その2段上にある「Font (set after reload)」を「Meiryo UI」にする
3. ScriptをUnicodeにする（と、いいのではないかと思う）

という手順になる。最も注意すべきは、「2.」だ。必ず日本語の「UI」書体を選ばなければならない。間違えて「MS ゴシック」などにすると、グリフのバウンディングボックスが負の値になるのかわからないが、一文字の大きさが巨大な横長になってしまい、もとに戻すのも一苦労だ。運がよければ、言語を「English (en)」にした時点でだいぶましになるが、そのあとで「Default Value」のボタンをクリックして、「Apply」または「OK」をクリックしなければもとに戻せない。レジストリをいじって解決することもできるかもしれないが、探した範囲では設定は見つからなかった。かといって設定ファイルも見当たらなかったし、再インストールしても以前の設定が残るので手が出ない。

なお、QUCSの開発は止まっているというような記述も一部にある。後継プロジェクトはQucsStudioらしい。QUCSにもASCOという最適化ツールやOctave（MatLabのGNU版）スクリプトを用いたシミュレーション結果の視覚化などが同梱されているが、QucsStudioはさらに多数のデバイスやシミュレーション手法、プリント基板設計やガーバーデータ出力などまで含むようで、なんだかたいへんなことになっている。Qt4ベースにも書き換えられている。しかし、GPLのQUCSをベースとしながらソースコードが公開されていないしWindows専用ということで、いまひとつ食指が動かない（起動はしてみたが）。いまのところ言語ファイルも英語とドイツ語のみ（ドイツ語のqmファイルから日本語に翻訳すればいいのかもしれないが）。

それから、コマンドラインでよければ、NGSPICEというプロジェクトもある。各種OSで動く（ただしXが必要なので、WindowsではCygwin環境ということになる）。SPICE3に準拠しているので、本格的にエンジニアリング目的で使うなら、こちらのほうがいいのかもしれない。

ついでに、QUCSはgplEDAというGPLに基づく電子回路設計ツールスイートプロジェクトの一部ということになっていて、プリント基板設計ツールや、Arduino本でおなじみの、ブレッドボード配線図などが描けるFrizingなどがファミリーとなっている。gEDAだけでも、シミュレーション以外の、回路図を描いたりプリント基板設計したり、ガーバーデータ出力したりすることはでき、WindowsでもMacでも動くので、一見の価値はあるかもしれない。

IPv6は普及しない

主に技術者や研究者、それから組織のネットワーク管理者や一部の経営者に誤った考えが広まっているので、念のために確認しておく。

あきみち氏のブログや記事で繰り返されていることでもあるのだけれど（例えばこれ）、IPv4とIPv6は全く違う設計のネットワーク。同じなのはパケット通信であることと階層的なデザインになっていることぐらいで、それならIPを使わない他のパケット通信方式も同じことになる。

よく「IPv6への移行」とかいわれるのだけれど、そうするとなんだかお引越しのようなニュアンスがあって、かなりの嘘が入ってると考えられる。なにかこう、IPv4ネットワークを使いながら、IPv6の通信が使えて、知らない間にIPv6になっているようなイメージ作りの意図を感じる。まるで新製品への買い替えを促しているようで、そうなると技術用語ではなくビジネス用語なのではないか。

IPv4は、「いまあるネットワーク」。一方、IPv6は、「動いているが限られた人が使っているネットワーク」。そして、いまどきの「インターネット」という商品を買っている人にとって、IPv6は全くメリットがないことを強調しておきたい。例えば、GoogleはIPv6ネットワークにも存在しているけれど、GoogleのサーバにないもののほとんどはIPv4ネットワークに存在している。したがって、IPv4ネットワークにしかないリソースへのアクセスは、IPv6ネットワークではできない。多くの人がAmazonとかiTunesとかFacebookとかに接続するだけなら、それらがIPv6ネットワークにサービス提供すればそれでいいのだけれども、それだけのことだ。しかし、IPv6でなければならない理由にはならない。実際、自宅や職場や無線通信でネットを利用している人は、「そこに到達すればよい」のであって、どんな通信手段を使っているかには注意を払っていないはずだからだ。

IPv4のアドレス枯渇がIPv6の設計動機であったことは歴史的に間違いない。だけれども、その時代の「インターネット」といまのネットは世界が全く違う。当時はこれほど、ネットに接続する人々が、プラットフォーム提供者のビジネスを、接続する人々が（広告など間接的にであれ）「購入する」という分断された関係ではなかった。

スティーブン・レヴィの著書「ハッカーズ」（工学社から翻訳が出ている）は、PCやネット黎明期の息吹を現在に伝える貴重な資料だが、PCもインターネットも、もともとアナーキーな若者たちによって理想と考えられ、取り組まれてきた結果普及してきたものだ。そのひとりで、誰もが知っている人物がスティーブ・ジョブズ。彼も60年代のカウンターカルチャーにどっぷりと浸かった時代の若者だった。ドラッグ使用の過去があるのは当然だ。インターネットは、60年代頃に、マサチューセッツ工科大学（MIT）の「テック鉄道模型クラブ」の連中が、巨大な鉄道模型システムを制御するために使っていた電話会社の中古のリレーの組み合わせに頭をひねっているときに、当時アメリカ唯一の電話会社AT&Tの技術者に食い込んで、電話システムのしくみに興味をもち、巨大システムの硬直性と脆弱性に気づき、無料で世界のどこにでも（海外の政府機関でさえも）キャンパス内の公衆電話から通話できる、その手口を明らかにすることに熱中したことと、他の一部のメンバーがMITの計算機センターに常駐するIBMの管理者に自由な利用を制限されることに嫌気をさして、AIラボに納品された、当時としてはとても小さな（といっても広い実験室でなければ設置できない）コンピュータの利用許可を、「夜中に利用者がいない時間に限る」という限定付きで得て、誰もいないことをいいことにハードウェアをいじりまわして機能（演算命令）を追加したり、ついに電話回線につないでしまったことからはじまっている。その時点で、「自分がやりたいことを実現するための、自分のためのコンピュータ」「作成したソフトウェアの共有と改良」「コンピュータを電話回線を通して通信する」という考え方が生まれたとされている。それに、西海岸で起こった、マイクロプロセッサの発明が加わって、PCの実現、フリーソフトゥエア、コンピュータネットワークが「草の根の運動」として発展していくことになる。ここでは、PCやネットワークの利用者は、皆が平等で、また限られた資源を共有することの暗黙のルールがあった。いまの、サービス提供者と利用者が分断された状況とは全く違う。

長くなってきたので、残りははしょる。

IPv4ネットワークは、もはやビジネスや政治の道具だ。中東の独裁政権打倒運動も、バラク・オバマ大統領誕生も、国際テロ組織による秘密のネットワークも、どれもIPv4ネットワークの上にある。

一方で、IPv6ネットワークは、かつての「ハッカーたち」の理念を引き継いだ、「相手の顔が互いに見える」ネットワークの理想を胚胎したまま、実験的に構築されているネットワークだ。もし、IPv6ネットワークをいまのまま発展させるならば、ビジネスや政治とは無関係な、草の根の人々の道具として維持していかなければならないことになる。ここでは、IPv6ネットワーク利用者は、サービスを金で買ってあとはしらんとか、自分の満足のため他の利用者の利害に影響を与えてもかまわない振る舞いをするといったことはできない。

いま、IPv4ネットワークの上での活動に自分が満足しているならば、IPv6を使う必要はないし、IPv4ネットワークの実情がIPv6ネットワークにそのまま持ち込まれることは、いまIPv6ネットワークにいる人々は望まないだろう。

IPv6ネットワークが一般化しないと主張する最大の理由は、「IPv4アドレス枯渇問題は、未だアドホックな対応で対処可能」という理由による。具体的には、Large Scale NATの導入で、いままで大量のグローバルIPアドレスを必要としていた通信事業者が、顧客の増大に対してIPアドレスを確保する必要がなくなる、ということに尽きる。そもそも家庭へのネット接続にはprivate IPアドレスしか原則として与えられないし、それをさらに家庭用IPルータで別のprivate IPアドレスに変換して使っているのが実情だ。企業においても、クラウド利用によって、外向きのIPアドレスはそんなにたくさん持たなくても十分な計算資源を持つことができるようになっている。多重NATの問題などは、ほとんどの利用者は気にしていないだろうから、本当にISPや国レベルでのprivate IPアドレスの利用がなされたとしても、大きな混乱はないだろうと考えられる。個別の問題に対しては、随時アドホックな対応で解決が図られていくだろう。

だから、（実はこれがいちばん言いたいことなのだが）「IPv4とIPv6のデュアルスタックでのシステム構築」とか「IPv4とIPv6のゲートウェイについての配慮」とか、いろんな案件が業者や知ったかぶりの利用者から寄せられると思うけれども、そんなのは金と労力のムダなので相手にしてはいけない。

IPv6ネットワークは、可能であれば予備の回線で独立に、そうでなければIPv6パススルーするスイッチやルータの設置にとどめ、あくまで別のネットワークとして構築するとともに、ネットワーク設置する立場にある人は、「IPv6をみんなに使わせなければ」などといった使命感は持たないことだ。導入する以上、コスト負担の問題が発生するから平等に行き渡らせることで受益者コスト負担を避けようというのは健全な思考だろうけれども、労多くして功少なしの結果が強く予想されるので、「やりたい人にやらせる」「コストは受益者負担で」というのが現実的ではないか。

いずれにせよ、「いまのIPv4ネットワークは延命される」という予想と「IPv6は別物」という事実によって、IPv6は絶対に普及しない、というのが僕の主張。

Kinectを500円で買った

名古屋大須のジャンク屋をみていて、Kinectが500円で置かれているのに心ときめき、即座に購入した。

O'reillyの「Making Things See」をななめ読みして興味を持っていたのでこれはありがたいと、早速ソフトウェアを準備。

Macの場合、OpenKinectことlibfreenectを入れることになるようだ。そして、libusbにパッチを当てたものが必要とのこと。

しかし、Xcode 4.3を入れてしまったため、MacPortsが使えなくなっている（upgradeが通るものがないわけではないが、まっさらからでは何もできない）ため別の手段をとったのだが、いろいろと問題含みだった。なお、MacPortsでサーバにしているMac miniはXcode 4.2.1をDeveloperサイトから落として、バージョンを下げておいた（ただ、command line toolsが4.3なのでコンパイル時に怪しげな警告が出たりする）。

以下経過。

まず、開発マシンは/opt/local以下をすべて消してMacPortsを一掃し、Xcode 4.3でもよいというHomebrewに移行することにした。brewコマンドのだいたいの使い方を覚えて、wgetとかlvとかが手軽に入ることがわかったのだが、libfreenect/platform/osx/homebrew以下のformulaは依存関係が不足していてだめ。また、ゆうべあたりにautoconf, automake, libtoolがいっせいにバージョンアップしたせいか、これらを先に入れてもautogen.shのなかで落ちてしまう。ちなみにautogenが入らない件、tracはclosedになっているが全く解決していない。--use-llvmを追加してもだめ。

で、しかたがないのでReadme.asciidocにしたがって、手で該当バージョンのlibusbを落としてパッチを当てるのだが、やはりautoconf.shが通らない。いちかばちか、www.libusb.orgから最新の1.0.8のtarballをもってきて、パッチがrejectした部分を自己判断でなんとかした上で、configure; make installした。動くかどうかはつないでみないとわからない。

brewにおけるformulaの扱いがまだいまひとつわかっていないので、次はやむをえずlibfreenect全体をgit cloneして、cmakeをbrew installしたのち、cmake .; make installしておいた。

さて、あとはKinectをMacにつなぐだけだ... と思ったら、コネクタの形状が違う。USBなら4本のはずが、オスメス違うし、よく見ると9端子だ。で、ざっと検索したところ、Kinectは外部電源が必要で、ACアダプタとUSBに分岐するケーブルが別にあるということだった。普通に買えばセットになっているらしいが、古いXBox 360持ちで何らかの事情がある人はマイクロソフトから4000円弱払って買うらしい（本体のシリアル番号を言わないと売ってくれないらしい）。でもたぶん中古があるはずだと検索してみたところ、アマゾンと楽天で1980円プラス送料（480円）で新品を扱っているところが出てきた。ヤフオクも同じ値段。ではさっそくそのへんで...と思ったが、こういうときはeBayを見るのが鉄則である。すると、簡単に日本向けshipping $0.99で本体$7.99というのが出てきた。USからであることと、送料が安い（国際宅配便なら$40はかかる）ことを考えると、船便で1ヶ月弱の納期を考える必要があるが、急がないならかなりお得といえる。

だが、こんなものにお金を払う連中ばかりではないはず。たいていのゲーム周辺機器は事細かに解析されているものだ。というわけで、「Kinect USB adapter DIY」で検索すると、ちゃんと自作記事が出てきた。ありがたや。元記事はこちら。9pinのうち、5本を下にして、USBに対応する（配列は違う）のは下の右4本、左は上下が+12V（1A以上必要らしいので分配しているのだろう）、上の真ん中2本がGND、右上は未使用ということのようだ。あとは作るだけ。よかった。

なお、外部電源の件だが、Kinectは台座にモーターが入っていて回転する。また、カメラが可視光と赤外光の2つが入っているし、赤外光ライトもあるので、USBの5V最大500mAでは心もとないに違いない。モーターといえば、PlayStation 2のDual Shock 2も振動モーター回転のためには7〜9Vの別電源が必要だ。

MozcもGoogle Updateの対象になる

Googleが様々な手段でユーザのコンピュータ（及びスマホなど）の利用状況をデータとして収集していることが懸念されているわけですが、Webブラウザに関しては、Webkitエンジンの代表格であるGoogle Chromeを外して考えるわけにはいかなかったところを、ChromeのソースがChromiumという形でオープンソースになっていることから、懸念される情報収集及びその送信部分を取り除き、正しく動作するよう大量のコードを加えた「SRWare Iron」を使うことで、心配から逃れるすべがありました。

他によく使われているのはGoogle Earth、そして日本人は「Google日本語入力」を使っている人がたくさんいるのではないかと思います（僕もそのひとり）。

Google日本語入力は辞書の優秀さとサジェッション（候補表示）の巧みさから、商用のIMEを購入して、OSバンドルのIME（WindowsならMS IME、Macならことえり）の阿呆さ加減を克服するのをためらわせるほどの魅力があります。

ただ、もしGoogle日本語入力が入力内容をGoogleに送信していたら、と考えると、これは究極のキーロガー（キーボード入力を記録して第三者に送信するプログラム）ともいえることになってしまいます。

そこで、Google日本語入力のオープンソース版であるmozcはどうなのか、ということになるのですが、mozcはGoogle日本語入力で使われる辞書は使うことができないようになっており、かわりにIPA（情報処理推進機構）が作成し、公開している辞書を使うようになっています。ソースがすべて公開されていることから、キーロガー的ななにかや、使用状況をGoogleに送信していないかどうかなどを確かめることができます。

そこで、mozcのソースを、ごく簡単に、ざっくり見てみました。

すると、「omaha」という語を含むキーを作成したり登録したりする処理が最初に目につきました。これは、Windows用の部分では、レジストリをアクセスして、内容を確認したり登録したりします。そして、そのレジストリキーの名前が「Google\Update」なのです。

Google Updateといえば、Googleのソフトウェアを入れると必ず入るプログラムで、MacでもKeystoneという形でマシン起動時にデーモンとして起動しますし、Windowsでプロセスマネージャーを見ると、GoogleUpdate.exeというプロセスとして確認することができます。

ChromeやGoogle日本語入力は、特にアップデート作業をしなくても、「いつのまにか」最新版に更新されています。いままでこの理由を説明するサイトは見当たらなかったのですが、要するにつねにGoogleと通信して最新版かどうかを確認し、そうでなければダウンロードして勝手に最新版に置き換える挙動をGoogle Updateが実行しているのです。

問題は、このとき、コンピュータなりスマホなりに固有のIDを作成してGoogleに登録しておくという動作が含まれていることです。これによって、Google側ではソフトウェアの更新状況や利用状況を把握できるというわけです。それだけなら会社で共同で使っている人は気にしないかもしれませんが、Googleアカウントとひもづけられると、誰がどのソフトウェアをどのぐらい使っているかということが、個人の他の属性（氏名、居住地、その他GoogleアカウントやGoogle+などのプロフィールに登録した内容）と関連付けられてしまうということになります。ある意味、Googleへの忠誠度がはかられているといえるかもしれません。

そして、「omaha」ですが、これはGoogle Updateのオープンソース版だそうです。

Omaha - Project page

Googleによれば、Google Updateが不審なプログラムと捉えられることは望まないので、どのような挙動をし、どのような通信が行われているかを、その仕様と実際のプログラムを文書とソースコードとして公表した、ということなのだそうです。

結論からいうと、mozcにはOmahaが入っています。したがって、mozcをインストールしたことはGoogleが把握していますし、どのバージョンが使われているかをGoogleは知っています。どのマシンで使わているかもGoogleは知っています。もしかしたら、勝手に最新版に置き換えられているかもしれません。

Ironはドイツで作られ、メニュー等の表示の翻訳をどなたかが提供される形で日本語対応がなされていますが、mozcに関しては日本人自身があらゆる作業に取り組まなくてはいけません。Ironは単にコードを削っただけではなく、相当量のコードの追加が必要だったとフォーラムで開発者が明かしています。mozcはChromiumと比べれば非常に小さなコード量ですが、Chromium由来のソースがたくさん含まれています。オープンソースですから、派生プログラムを作成して公表することに法的な問題は全くありません。ソースコードには、Googleからの派生物であることを明示し、Googleがつけたクレジットさえ書き換えなければよいと書かれています。ライセンスはBSDですから、要するにas-isです。どなたか腕に覚えのある方、mozcをクリーンにするプロジェクトに取り組んでみませんか。