SVX日記

　 むぅ。やはり平日に車に乗らない生活をしていて、毎日車に関する日記を書こうというのは無理があったか。というか、毎日車に乗る生活をしていても無理があるよな、たぶん。

　 というわけで、今日は昨日の「車版フライトレコーダ」の構想について書いてゴマかす次第である。ちなみにこの「ごまかす」とは「ごまかし」の活用形で「ごまかし」とは「胡麻菓子」と書く。これは昔あった「胡麻胴乱(ごまどうらん)」という菓子の俗称で、この菓子が中空構造で「見掛け倒し≒ごまかし」であったことに由来しているが、ここでそんなことはどうでもいいことである。

　 SANYOのDSC-SX150というデジカメが手元にある。このデジカメは固定焦点150万画素ということで、今となってはカタログスペック的に見るところのない製品なのだが、その洗練された操作スタイル、レスポンス、画質には光るものがあった。私もしばらく愛用していたのだが、ひとつだけの欠点がバッテリーの持ちが悪いことである。このデジカメ、バッテリー室は単三型x2で、メタハイの使用が推奨されているが、イザとなったらアルカリも使用できるという、非常に私好みのスタイルなのである。しかしながら、それにつけても電池が持たな過ぎるのであった。

　 末期には電池を入れて数十秒でバッテリー警告等が点くようになったばかりか、電池室のフタが欠けてしまい、使い物にならなくなってしまった。前者の問題に関してはどうやら電池室の接点を掃除することで解決するらしいことを最近になって知ったのだが、既にリコーのCaplioG4wideに取って代わられてしまっているので、今となってはどうしようもないのである。

　 で、このジャンクデジカメを「車版フライトレコーダ」へ活用するのである。

　 まず、このデジカメを車のアクセサリー電源に直結できるように改造してしまう(当然、3.3Vへの降圧はする、三端子レギュレータで一発である)。このデジカメ、メカニカルスイッチにより電源が入るのでON位置に固定しておけば、それだけで車の走行中、常にデジカメを起動しておくことが可能になるのである。さらにレリーズボタンから線を引き出し、PICマイコンから撮影を制御できるようにし、PICマイコンから1分間隔程度のインターバル制御でシャッターを切るわけである。

　 近年、コンパクトフラッシュの容量は飛躍的に増大しているので、8時間車で走りつづけて480枚、十分に格納できるであろう。これさえあれば、ドライブのよい記録になるばかりか、万が一の事故の際には証拠写真となる可能性もある。

　 とりあえずバラしてみたところ、今日はなんとかレリーズ回路を発見するところまできた。明日は線を引き出すことができるか、というところである。

　 なお、今日は紙工作も作ってしまった。

　 誰が言ったか知らないが、所詮人生死ぬまでの暇潰しである。それにつけてもモノ作りの楽しさよ。ちゃんちゃん。

　 昨日、オイラがゼビウスでシラフで進むことのできるエリアを再確認してみると書いたが、早速やってみた。サクサクとエリアをクリア、残機を1機を残した状態でエリア13まで進み、バックゾシーを越えるか越えないかあたりで撃墜された。今日こそ越えたと思ったんだがなぁ……後ろから飛来したゾシーを左に大きく回りこんだ先に、港の上のログラムから放たれた一発のスパリオが待ち受けていた。つーか、そこで弾を撃つか？　もう20年以上の付き合いになるが、オマエさんソコまで性格ワルかったっけ？

　 ラスト1機は出撃直後に出現したブラグザカート群にあえなく撃墜。ちゅーか、キツすぎだぞブラグザカート。そんな近くで破裂されたら、絶対に避けれないっての。結局、オイラにとってはエリア13が鉄のカーテンであるコトを再確認させられた。ぐぅ。

　 さて、ゼビウスは置いておいて、工作しなきゃイカんモノはあるのだが、なんとなくいまひとつノリが悪い。そんなノリの悪い時、ノリを良くする薬効を持つのがビールである。ただし、薬というモノには副作用もあるわけで……早い話、ノリが良くなったせいでウイスキーのダブルを追加インストールしてしまい、今日もオーバラン、別の意味でガストノッチな気分になってしまったのであった。えーぃ、再グワッシャじゃッ!!

　 今日の酒量は昨日より控えめとはいえ、やはりアルコールはソルバルウの操縦に意外な影響を及ぼすようである。運もあるとは思うが、シラフならさすがにバキュラに激突死したりはしないと思うのだよな。また、酒を呑むと後半の攻撃に弱くなるようで、70%を越えているために次のエリアに進むとはいえ、そこで残機をすり減らしてしまう傾向があることがわかった。

　 うー、昨日よりも調子がいいような、悪いような……あー、ヤベェ。コレが最後のソルバルウだ。こんなんじゃ昨日の場所まで進めんぞ……と思ったら、なんと偶然にも、エリア11の後半のナナメに地上物が並ぶ、昨日とまったく同じ場所でゲームオーバになったではないか。うーむ、なんと恐ろしいほどハッキリとした結果だ。

　 結局、シラフだとエリア13の後半、適当な酒量だとエリア11の後半という結果が得られた。12を14で割ると0.86であるから、オイラが適度に酔っ払うと10〜20%の能力低下が見られる(？)という結論である。今後はもう少しガンバって、かなりの酩酊状態でもしっかりとエリア13まで進めるように精進していきたい(？？)。

　 とりあえず

　 ちゅーわけで、tDiary用の「ゲイツ認証」プラグインが完成した。つーか、実は一昨日に記事を書いた時点でかなりの状態までできていたのだが。

　 で、一昨日の時点では「SVX認証」などという名称の予定であったが、この名前はヤメた。というのも、肝心の多数のSVXのイメージを十分な品質で揃えられなかったからである。オレ著作権で大量の同テーマの写真というと……実は昔こういうサイトを作っていたもんで……あるんですな、大量の「送電鉄塔」の写真が。というワケで「鉄塔認証」という名称にした。英語名「PylonAuth」。中国名「白竜逢瀬」(←ウソ)。

　 別にこのサイトに認証を適応するつもりはないが、ココで動作を試すことはできる。主に、検索エンジンやウェブアーカイバを排除するために作った認証方法である。

　 なお、CAPTCHAイメージはImageMagickのconvertコマンドを使って合成しているので、ちゃんと1枚のイメージになっており、こういうマヌケなコトにはなっていない。また、サーバで正解を保持するのはやっかいなので、認証情報はクライアントから送り返すようになっているが、正しくMD5を使っているので、理論的に破ることは十分に困難であると思われる。

　 認証に使うイメージの枚数は可変なので、それを8枚くらいにして、真にイメージの法則を知っている人間しか正しい選択ができないようにすれば、実用的な認証にもギリギリ利用できるかもしれない。もし、何らかの方法で1枚のイメージに2個のチェックを付けられるように工夫すれば、5枚で10ビットとなり1024通りだ。こうなれば数字3桁のCAPTCHAと同程度の防御率となる。

　 また、CAPTCHAイメージを毎回生成するとサーバの負荷がバカにならないので、頻度を下げ、過去のイメージを使いまわすことができるようにも作ってある。デフォルトでは新規生成は10回に1回、100個のイメージを保持し、使いまわすようになっている。

　 プラグインはGPLで公開する。プラグイン本体とサンプルの鉄塔認証データ。インストールの方法はmisc/plugin/pylonauth_plugin.rbにコメントとして書いてある。

　 まだ、インストールした事例が少ないのでバグがあるかもしれないが、そういう場合はソース読んで直してパッチを送ってくれるとうれしい。ほんじゃ。

　 ……関係ないけど、懐かしい写真が出てきたので載せておく。SVXの前に乗っていた、ソアラのエアロキャビンだ。ちなみにペイントはPhotoShopによる合成で、このような状態で乗り回していたわけではない。赤丸の中はスキャナの調子の悪さを表現するためのもの(これを機にフィルムスキャナを卒業した気がする)。

　 Fedora9、××チューンシリーズはもう少し続くが、今日は小休止。ネタとしては似たようなもんだが。

　 オイラは以前にSIRENというメーカのUM-100-512SというUSBメモリを名指しで購入したのだが、最近になってそのチップがSLC構造だと知った。かなりの時を経てのイキナリのポイントアップだ。

　 オイラは過去に、特に下調べせずに買ったCD-RドライブであるCD-R56S-600、主力機が死んで慌てて買ったマザーボードであるCUB-Xと、かなり使い込んだ後で、それが名機であったことに気づかされることが度々あるが、それを想起させる。

　 で、改めてそれをモバイルCVSレポジトリにしようと思い、ゴチャゴチャとした中身を吸い出して、フォーマットしようとしたのだが、悩んだのがvfat領域をどうするかということ。やはり、ちょっと使いたい時のためにWindowsからも使える領域があった方がいい。

　 fdiskしてジオメトリを確認してみる。

Disk /dev/sdc: 523 MB, 523632640 bytes
255 heads, 63 sectors/track, 63 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

　 全部で63シリンダだ。するってーと、ext3に49、vfatに14、あたりで割るのがいいかなぁ……っと、そうだ。その前に、スッキリとゼロクリアしておくか。ついでにパフォーマンスも計っておこう。

# time dd if=/dev/zero of=/dev/sdb
dd: writing to `/dev/sdb': デバイスに空き領域がありません
1022721+0 records in
1022720+0 records out
523632640 bytes (524 MB) copied, 248.831 seconds, 2.1 MB/s
real    4m8.864s
user    0m0.742s
sys     0m3.612s

　 よし、改めてfdisk、と……あ、あれ？

Disk /dev/sdb: 523 MB, 523632640 bytes
17 heads, 59 sectors/track, 1019 cylinders
Units = cylinders of 1003 * 512 = 513536 bytes

　 なんか、さっきとジオメトリが変わってるような……いや、さっきは間違いなく63シリンダだったハズッ!!　なんだこれぇ!?　ヘッドやセクタって装置に固有だったんじゃないのぉ!?

　 こんなことが起きると、ちょっと計算してみたくなる。ヘッドｘセクタｘシリンダ数……いわゆるCHSで使える容量と、一番上のバイト数との差だ。

17 x 59 x 1019 x 512 = 523,293,184
523,632,640 - 523,293,184 = 339,456

　 結構な差がある。つまり、この339KB強は端数であり使えない領域なわけだ。こんな無駄はなくしたい。つーか、もしかして、このあたりの数値ってfdiskで指定できたりなんかしちゃったりして……

# man fdisk
 
-H heads
　Specify the number of heads of the disk. (Not the physical
　number, of course, but the number used for partition tables.)
　Reasonable values are 255 and 16.
 
-S sects
　Specify the number of sectors per track of the disk. (Not the
　physical number, of course, but the number used for partition
　tables.) A reasonable value is 63.

　 ……できるじゃんッ!?　もちろん物理番号じゃないぜ、って書いてあるけど、もともとこれらは物理的な概念でしょーが。驚いたなぁ、もう。

　 となると、うまくすれば、無駄な領域をゼロにできるんでない？　manページには255と63がリィズナボォ(妥当)とあるけど、その論理がわからん。いいや、試しちゃえ。

　 で、ここでリングに上がるのが素因数分解。昔、授業で習ったよね。523,632,640 をガッツンガッツンと2で割るぜッ!!

　 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 5 x 799ッ!!

　 799って素数っぽいけど、素数だっけ？　確かめるために「素数」でググる……わ。素数じゃないっぽいぞ。確か、デカい数値の素因数分解って、RSA暗号の基礎理論であり困難だと聞くが(ケタが違うって)……できるかいな。3で割って、7で割って……ダメだ。ヤケクソで17で割って……

　 799/17=47

　 ……あ、割れた。素数リストを見ると、17も47も素数だ。素因数分解完了ッ!!

　 これの値をどう使うかというと、こう使う。

# fdisk -H 47 -S 17 /dev/sdb
Disk /dev/sdb: 523 MB, 523632640 bytes
47 heads, 17 sectors/track, 1280 cylinders
Units = cylinders of 799 * 512 = 409088 bytes

　 どれどれ、シリンダ数は……1280か。17 x 47 x 1280 x 512は523632640……523632640ッ!!　で、出たッ!!　ホールインワンッ!!

　 つーわけで、USBメモリの端から端までキッカリと確保することに成功したようだ。こりゃあ気分がいい。例によって、先頭をちょっと空けてふたつの領域に切る。

Disk /dev/sdb: 523 MB, 523632640 bytes
47 heads, 17 sectors/track, 1280 cylinders
Units = cylinders of 799 * 512 = 409088 bytes
Disk identifier: 0x00000000
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               3        1024      408289   83  Linux
/dev/sdb2            1025        1280      102272    6  FAT16

　 1シリンダのサイズが400KB程度と小さいから、先頭に空けておく領域も1MB以下で済んでいる。なんだよー、こんなことなら、プライマリドライブとして使っているコンパクトフラッシュも工夫すればよかったよ。

　 こっちは、16,240,345,088バイトだから……(2^27) x 11 x 11ッ!!　こっちもキレイに割れるじゃんッ!!

　 一方で、セカンダリドライブである16GBのSDカードは、16,071,000,064バイトだから……2^19×7×29×151……少し微妙だが、7と29を使えば、こっちもキッカリと使い切ることができる。うわぁ、フォーマットをやり直してぇ!!

　 なお、このジオメトリという概念は、記憶領域の一部に記録されているものではなく、パーティションテーブルの「雰囲気」や、単純に固定値が採用されるようである。fdiskのソースは以下のようになっている……

    922     get_kernel_geometry(fd);
    923     get_partition_table_geometry();
    924 
    925     heads = user_heads ? user_heads :
    926         pt_heads ? pt_heads :
    927         kern_heads ? kern_heads : 255;
    928     sectors = user_sectors ? user_sectors :
    929         pt_sectors ? pt_sectors :
    930         kern_sectors ? kern_sectors : 63;

　 ……ユーザが指定すれば、言い値が採用されることがわかる。しかし、CHSがここまで、観念的な概念に落ちぶれていたとは意外だなぁ。

　 ひとつ疑問が残ったのは、そもそもフラッシュディスクの総容量がどう決まっているのか、ということ。相手が円盤なら端数も出そうなもんだが、ゴ盤の目のような構造(たぶん)のメモリで、こんな素数が出てくる道理がわからない。

　 CRCや欠陥セクタの領域を除外した結果なのだろうか？　どっちにせよ、フラッシュの内部的な物理記録の単位となんらかの関連があるかもしれない。キッカリ合わせると書き込みが効率化するなんて御利益があったりしたりしてね。ほんじゃ。