(2015-01-18追記:64ビット対応を果たしたDiskWarrior 5が出たので、再び神ツールの座に舞い戻ってきたかもしれない)

久々にTime Machineのsparsebundleが壊れた。

fsck_hfsで修復出来なかったのでDiskWarrior 4.4を引っ張り出してみるも「There is not enough memory. Restart from the disk warrior disc and try rebuilding again. If you report this error. Please mention the error code (2154)」と言われて修復不能。32GB積んでるマシンなので、実際メモリ不足って事はないと思うんだけどなぁ。

修復処理を始めてすぐにエラーを吐くので、恐らく修復対象ボリュームのファイル数から必要なメモリ数を見積もり、処理出来るか判断してるのだと思う。DWは32ビットアプリのようなので、使えるメモリの上限は4GB。この制限は仮想メモリを使っても突破出来ない（物理アドレス拡張を使えばこの限りではないが、DWが対応してるとも思えないし、そもそもOS XでPAEアプリを作れるかも不明）。要は、扱えるファイル数に上限があるって話ですな。Time Machineの性質上、バックアップ先のファイル数は大きくなりがちで、2154エラーで検索するとTime Machineの修復で発生している事例が多いのも頷ける。

では、DWが扱えるファイル数の上限はいくつだろうか？

DWのロジックが分からないので完全な推測になってしまうが、ファイルシステムの構造(B-Tree)を弄っているのは間違いないだろう。Technical Note TN1150: HFS Plus Volume Formatによると、1ノード(BTNodeDescriptor)≒1ファイルあたり14バイトとなっている。アライメントも考慮してキリよく16バイトとし、メモリ4GBフルに使ったとすると2.6億ファイルとなる。ちなみに、自分の手元のマシンは約52万ファイルを有しているので、500台分のファイルを扱える計算だ。

この数値だけなら十分大きいように見えるが、実際は4GBフルに使える訳じゃないし、1ファイルあたりの消費量ももっと大きいだろう。多めに見積もっても、せいぜい1億ファイルに届かない位なんじゃなかろうか。自分の感覚で言わせて貰うと、今の時代、少なくは無いが安心出来るほど多くもないって所かな。

まぁ、普通のボリュームに対してなら、まだまだ必要十分なスペックだろうけど。積極的にメンテされてる雰囲気がない点も気になるところ。

DiskWarriorとは全く関係ないが、sparsebundleの分割サイズ、もう少し大きくならんかねぇ。今どき8MBだと、分割数が数十万とかになっちゃって削除するのも一苦労なんだけど…。

Xcode 4のSubversionが1.7のため、MacPortsで1.8が入ると色々と面倒なので、敢えて1.7にダウングレードしてインストールする。

unicodeパッチを標準で取り込んでくれたら、MacPortsから入れる必要もなくなるんだがねぇ。

svn co http://svn.macports.org/repository/macports/trunk/dports/devel/subversion --revision 108493
cd subversion
sudo port install +unicode_path

Xcode 3を入れてる環境で

Error: The installed version of Xcode (3.2.6) is too old to use on the installed OS version. Version 4.6.2 or later is recommended on Mac OS X 10.8.

と言われた場合は、

sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer

として開発環境をXcode 4に切り替えればおｋ。

• Philipps Blog » Downgrading Subversion from 1.8 to 1.7 in MacPorts
• macports - "The installed version of Xcode (3.1.4) is too old" error in port after installing Xcode 4.3 - Stack Overflow

RAW+JPEGで撮影された写真をLightroomの自動スタックでまとめてたら、スタックされない写真があった。調べてみるとPENTAX QのRAW+で生成されたRAWとJPEGだった。

自動スタック機能は撮影時刻から同一シーンかどうかを判断している。当該写真のExifを見ると、RAWとJPEGで撮影時刻が違ってやんの。RAWの方がJPEGより数秒後に撮られた事になっている。多分それぞれのファイルの生成時刻が記録されてるんだろうけど、同一ショットのRAWとJPEGを記録するモードなんだから、同一時刻になって然るべきなんじゃないかなぁ…。遅延時間が一定ならまだしもファイルによって違うから、自動スタックの条件変更でも対処出来ないから困る。

とりあえずリコーに「一致させて！」と要望を出してみた。

すると、ものの2時間程で返事が来た。内容はテンプレだったけど、土日はメールの対応くらい休んでもええんやで。急を要する内容じゃないからメールで問い合わせしてるんであってｗ まぁ、素晴らしい対応で感動した。次のファーム更新で直してくれたら更に感動するけど。

正月を挟んで少し時間が経ってしまったが、12/16にNTT-Xで注文したUP2414Qが12/29に届いた。

Mac Pro (Early 2009)にPC用のRadeon HD 7790を挿し、DisplayPortで繋ぐと3840×2160@30Hzで出た。現状、OS X 10.9.1に至までMST非対応のようなので、Macで4k60フレを出すのは無理っぽい。ゴミ箱Proは対応してるようだが、なぜかUP2414Qは30Hzになってしまうという怪情報も。林檎印の4kモニタが出ないのは、OS側の対応が不十分だからなんじゃないかと思う。UP2414Qを繋いだだけではHiDPIモードが有効にならず、単なる極小ピッチの見辛いモニタでしかないしさ。HiDPIで先行してた割には、なかなかお粗末ですな。てか、最近の林檎はiOSばっかに注力してて弛んでないか？

ちなみに、BootCamp上のWindows 7だと余裕で60Hzで出た。10.9.2βがMSTに対応してるらしいので、そのままリリースされてくれるといいんだけどなー。

OS Xで30Hzだとマウスポインタのラグが酷く、極めて使いにくい。SmoothMouse for OS Xを入れて操作感をWindows風にすれば、通常作業には問題ない程度には使えるようになる。少なくとも、ネット閲覧、プログラミング、素人の写真編集用途には必要十分。

リフレッシュレートの低さよりも3840×2160の解像度で得られる満足度のほうが大きい。特に写真編集には効果絶大！4k解像度を以てしてもDbDで全体を一度に見通す事は出来ないが、WUXGAに比べたら差は歴然。その代償として、今まで気にならなかったフリンジやら微妙なピントズレやら被写界深度不足やらが気になってしまい、嬉しいやら悲しいやら(´・ω・｀)

ようやくサブ機のMBAをMavericksにした（メインのMac Proは怖いのでMountain Lionのままｗ）。

気になるXcode 3のインストールはというと、Mountain Lionの方法がそのままで使えた。軽く使ってみた限り、問題なく動いている。まだまだ戦えるぜ！たまにエディタがバグって例外吐くけど、これはMLからなので……どうせコードはEmacsで書くので大した問題じゃないし。

全く関係ないが、OS初回起動時のようこそ動画、どうして止めちゃったんだろう。非常にAppleらしい演出で、新しい世界！新しいOS！自分だけのコンピュータ！って感じで凄く好きだったのに。

自分が初めて手にしたMacは初代Mac miniで、OSはTigerが出る直前頃のPantherだったけど、あの動画と最後のXからグルンと三次元的回転で初期設定画面に繋がる流れは、Windowsしか知らない自分にとっては超衝撃的だった。そこから一気にMacの虜になったことを覚えている。それが今や、何の感動もないぎこちない音声合成だもんなぁ……。