会社のMac(Mountain Lion)から隣に鎮座してるWindows 7にMicrosoft Remote Desktopで繋ぐと、操作に対する反応がワンテンポ遅れ、画面の描画も超遅い現象にずっと悩まされていた。アナログ56k時代の巨大画像読み込み（ツッ・・ツッ・・ツッっていうアレ）を彷彿とさせる遅さ。接続条件は遥かに悪いハズの、インターネット越しの自宅鯖の仮想マシン上のWin 7に繋いだ時の方が快適という酷さ＆謎っぷり。

で、やっとこの問題を解決出来た。

デバイスマネージャのネットワークアダプタの詳細設定で一括送信を無効にすると直る。NICの種類によってプロパティ名が違うのが厄介と言えば厄介。たとえば、Realtekなら「一括送信オフロード」だし、Intelなら「大量送信オフロード」って具合。とにかく、巨大データを一気に送る風な名前のプロパティだ。

ふと思ったんだけど、このプロパティってネトゲの通信に影響及ぼしたりしないのかなぁ。こいつに引っかかると、かなりのラグが発生するため、リアルタイム性を要求されるゲーム(FPSとか)では、かなり不利になりそうなもんだけど…。“大量送信”という名前から察するに、データ量が少なければ問題ないのかしらん。

(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に比べたら差は歴然。その代償として、今まで気にならなかったフリンジやら微妙なピントズレやら被写界深度不足やらが気になってしまい、嬉しいやら悲しいやら(´・ω・｀)