TidBITS: Apple News for the Rest of Us  TidBITS#624/01-Apr-02

あなたの Mac OS X 機を最後にバックアップしたのはいつですか?多くの人に当てはまる解が Retrospect 5.0 である - Adam が今週号でこの新しいリリースを深く掘下げている。そして、Matt Neuburg が二回にわたってユニコードとそれがあなたにとって何を意味するかについて取上げる。ニュースの部では、KeyStrokes for Mac OS X が障害をもつ Mac ユーザーで新オペレーティングシステムを使いたいと思っている人に役立つ適合支援技術を提供していることをお伝えする。 (謹告:今週号で取上げている記事は(#623 とは異なり)デッチアゲではありません!)

記事:

Copyright 2005 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: editors@tidbits.com>


本号の TidBITS のスポンサーは:


MailBITS/01-Apr-02

Mac OS X のためのキーボードアクセシビリティ -- Joe Clark が障害をもつ Macintosh ユーザーのためのアクセシビリティについて TidBITS シリーズを掲載した時に、彼は Mac OS X における適合支援技術の現状について嘆き悲しんでいた。しかし先週オランダの会社 Niemeijer Consult がリリースした KeyStrokes for Mac OS X が、適合支援技術の世界での Mac OS X の地位の改善に貢献できるかもしれない。KeyStrokes はスクリーン上にキーボードをグラフィカルに表示する;ユーザーは画面上の文字の上にカーソルを合わせて、マウス、トラックボール、ヘッドポインタ、またはその他のポインティングデバイスを用いてクリックする。カーソル合せは出来てもボタンをクリック出来ない人には、KeyStrokes はシステム全体で使える “滞在時間型” のユーティリティを提供する。これはターゲットに対してある一定の短い時間カーソルを静止した状態に保つ事で、クリック、ダブルクリック、そしてクリック&ドラッグを可能にするものである。テキストの入力は Mac OS X 内のいかなるアプリケーションでも可能で、Classic を走らせている状態でも同じである。キーボードレイアウトは U.S. 及び国際版があり、プログラムは Command キーとのコンビネーション、デッドキー(アクセントのための)、そしてモディファイヤーキーとクリックのコンビネーションをサポートしている。KeyStrokes for Mac OS X は $200 で、System 7.1 から Mac OS 9.2 までのための KeyStrokes 2.2 も含まれている;数量値引、アップグレード値引もある。まず試してみたい人のためには、完全に機能するデモ版が出されている。[ACE](カメ)

<http://www.assistiveware.com/keystrokes.html>
<http://db.tidbits.com/getbits.acgi?tbser=1189>(日本語)Mac とアクセシビリティ:エデンの園の課題
(日本語)Mac とアクセシビリティ:対応策
(日本語)Web のアクセシビリティ:見ずに Web をサーフする;
(日本語)Web のアクセシビリティ:Web の音声と映像
(日本語)Mac とアクセシビリティ:エデンの園を更にかいま見る


チェリーを2バイト - ユニコードと Mac OS X - その1

文: Matt Neuburg <matt@tidbits.com>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

もしもあなたが Mac OS X を使っているのなら、あなたのコンピュータには、あなたの知らないうちに、とてつもない変革が訪れつつある。いや、Unix の話をしているのではない。プリエンプティブ・マルチタスキングの話でも、その他よく言われるような、わけのわからぬ専門用語の話でもない。私が話しているのは、テキストのことだ。

テキストの変革って、いったい何のことだろうか? テキストなんて、当り前すぎておもしろくも何ともない。我々は皆、テキストをタイプして、読んで、編集して、保存して、普通に扱っている。たいていの人にとっては、そもそもコンピュータを購入した主な目的の一つがテキストだろう。テキストは手段であり、媒体であって、それ自体が目的ではないし、それ自身で明示的なものでもない。我々の手のひらの下にはキーボードがあって、キーを1つ打てば相応する文字が画面に現われる。それだけの話に過ぎないんじゃないか?

誰でも初めはそう思うだろう。けれども、テキストについて深く知れば知るほど、コンピュータ上でのテキストの動作方法がわかってくるほどに、ただタイプをすることができるということ自体のうちにさえも驚くほどの秘密が隠されていることがわかってくるのだ。どんなキーボードを使っているのか、個々のキーがどんなキーコードに対応しているか、それぞれのキーコードがどうやって文字によって表現されるか、それらの文字がどのようにして画面に描かれるか、その情報をどのようにファイルに保存するか、そういったことがすべて問題となる。言語、フォント、大文字と小文字、発音符付きの文字、ソート順序、その他のことがすべて関わってくる。

この記事では、そうしたテキストの、ある1つの側面のみに焦点をしぼってみたいと思う。それが、ユニコードだ。あなたがユニコードについて聞いたことがあろうとあるまいと、これは既にあなたに関係している。なぜなら、Mac OS X はユニコードのシステムだからだ。Mac OS X における文字列は本来ユニコードの文字列だ。Mac OS X 付属のフォントの多くはユニコードフォントなのだ。

でも、問題点はある。Mac OS X のユニコードへの移行は完ぺきというには程遠いものだった。ユニコードが動作しない箇所もいくつかあるし、きちんと実装されていない箇所も、操作の邪魔になるような箇所も残されている。きっとあなたもそういう問題点に遭遇したことがあるに違いない。その際あなたは、きっと肩をすくめてそのまま操作を続け、その問題の原因を気に止めもしなかったかもしれない。しかしこれからは、そういう問題に以前より少し気が付きやすくなり、その代わりに肩をすくめる回数が少し減ってくると思う。より重要なことは、この知識を得ることによってあなたの中に未来への準備が整う、ということだ。なぜなら、ユニコードの到来は避け難いものだから。Mac OS X の中ではユニコードが重要な位置を占めているし、今後ますますその重要度は増える一方だろう。ユニコードこそ未来、あなたの未来なのだ。私のお気に入りの映画の文句に言う通り、僕らは皆未来のことを考える、なぜって、僕らの余生は未来にあるからなのさ!

ASCII、異議無し! -- さて、未来を理解するためには、まず過去の理解から始めなければならない。

初めに光があった。もとい、文章があった。印刷機が、本が、タイプライターが、そして特に、電信線を通じて情報を送るための特殊なタイプライター、すなわちテレタイプがあった。古い映画などに出てくるのでご覧になったことがあるだろう。電送ニュースや軍事指令などを、テレタイプがカチカチと音をたてて打ち出す場面を。テレタイプ機は、タイプされたアルファベット文字を電気的なパルスにエンコードして送り出し、受け手の側でそれをデコードする、という仕組みで動作した。

コンピュータが登場してインタラクティブな遠隔操作が可能になった時、その情報伝達の手段としてテレタイプが流用されたのは自然の成り行きだった。こうして、コンピュータのための普遍的な標準“アルファベット”としての最初のものが、多少の悶着はあったものの、テレタイプの動作法をもとにして生まれた。これが ASCII(「アスキー」と発音される)すなわち American Standard Code for Information Interchange だ。いわゆる「コントロールコード」が含まれていることからもテレタイプの影響が見て取れる。これらの特殊コードは送信先のテレタイプ機をコントロールするために使用されたものだった。(例えば Control-G は送信先のテレタイプ機のベルを鳴らすコードで、着信機のオペレーターの注意を喚起するためのものだった。今日の電話着信音のようなものだ。)

当時からアメリカ合衆国がコンピューティングの世界での経済的・技術的な主要推進者であったので、ASCII 文字は自然とローマ字の大文字・小文字から成ることとなり、その他のよく使われる記号・符号やいくつかのコントロールコードも含められた。これらの文字セットはもともと 128 個の文字から成っていた。もちろん、この数字は2のべき乗である。当然ながら、バイナリというものがコンピュータの根幹を成していたからだ。

私が初めて Apple IIc を買った時、私は ASCII がいつの間にかさらに2倍、すなわち合計 256 文字から成っていることを発見して驚いたものだった。数学的にはこの数の方が自然だった。なぜなら、256 は 8 バイナリ・ビット、つまり1バイトであり、この1バイトというのがメモリーデータの最小単位だったからだ。つまりこれはメモリーデータを無駄なく使用できることを意味していた。けれども、新しく増えた 128 文字にどのようなものを割り当てるべきか、というのは大きな問題だった。(この新たな 128 文字は“high ASCII”文字と呼ばれて、従来の 128 文字、つまり“low ASCII”文字と区別された。)最大の障害はコンピュータのモニタ画面だった。当時のモニタでは、画面に表示されるテキスト文字はモニタのハードウェアに直結されており、“low ASCII”文字以外は扱うことができなかったのだ。

フォントが本当だ、言葉にも気を付けろ -- 1984 年になって Macintosh が登場した時、すべてが変わった。Mac のモニタ画面はグラフィックスを表示するだけのものであって、テキストを表示すべき際にはそれぞれの文字を構築する仕事はモニタのハードウェアではなくてコンピュータ自身が担当するようになったのだ。当時においては、これは世界中の人々をアッと言わせる、驚天動地の大革命だった。個々の文字をどのようなものにするかが完全に自由になったわけで、この時点に至って初めて、256 文字のすべてが誰にでも使えるものとなった。“high ASCII”文字にアクセスするためには Option キーを押せばよい。そうするだけで、素晴しい新世界が目の前に開けたのだ。黒丸! パラグラフ記号! セディラ付きの c! 何という感激! こうして、今日我々が慣れ親しんでいる MacRoman の文字セットが生まれたのだ。

コンピュータが文字を描くようになったということは、ユーザーが自由にフォントを選ぶことが可能になったということをも意味していた。これもまた、一つの革命であった。Venice とか San Francisco とかいう奇妙なフォントにしばらく熱中してから、皆がその熱から冷めた後になって、ユーザーたちは次第にこの革命の持つ真の意味に気が付きはじめた。それは、ローマン言語以外の言語を表示することが可能になった、ということだったのだ。256 個のキーコードに、MacRoman 文字セットの 256 文字を当てはめなければならないという必然性は何も無かった。別のフォントを使いさえすれば、全く 新しい 256 文字が得られるのだ。例えば Symbol フォントを見れば誰にでもこれは実感できた。実際、私が Mac に乗り換えたのも、まさにこれが動機だった。私は、ギリシャ語とか、デーヴァナーガリー(サンスクリットの字音表)や発音記号などを取り混ぜてタイプする必要があった。国際文字タイプライターと格闘したり、記号を手で書き入れたり、といったことを何年も続けた後だったので、これらすべての文字を自在にタイプセットできるようになったというのは、私にとっては第七天国に居るような喜びだった。

天国にもトラブルあり -- しかしながら、天国にもそれなりの限界があった。例えば私がある書類を印刷したいとしよう。レーザープリンタは高価なので、Mac ラボに書類を持ち込んで印刷しなければならない。けれどもそのラボのコンピュータには私の使ったフォントが入っているとは限らないのだ。すると、私の書類は私の意図した通りには印刷されないことになる。私が同僚に私の書類を渡した時とか、ファイルを出版社に送った時とかにも同じ問題が起こる。相手が私と同じフォントを持っていない限り、私の書類は正しく表示されないのだ。

Windows ユーザーが絡んでくるとまた別の問題が起こる。Windows コンピュータでの文字セットは困ったことに Mac での文字セットとは食い違っているのだ。例えば、WinLatin1(正確な表現ではないのだが、しばしば ISO 8859-1 とも呼ばれている)では、上下逆さまの疑問符(スペイン語で疑問文の開始に用いられる)はコード 191 に割り当てられているが、Mac ではその文字は 192 だ。(191 はノルウェー語のスラッシュ付き o だ。)

さらに、Mac ユーザー同志の間でも問題は起こる。「標準」のフォントというのはいろいろの異なった言語ごとに違ったものとなっている。なぜなら、MacRoman の 256 文字だけでは、さまざまのローマ字の変形を使用する各種の言語すべてをカバーすることができないからだ。例えばトルコ語を考えてみよう。MacRoman にはトルコ語の「点なし i 」は含まれているが、トルコ語の「セディラ付きの s 」は含まれていない。そこで、トルコ語用の Mac ではセディラ付き s をアメリカ用の Mac での“fl”合字の場所に割り当てている。同様のことが Windows 機でも起こるのだが、例えば Windows 機ではトルコ語のセディラ付きの s が別の言語では古英語の thorn 文字 (th) と同じ場所に割り当てられている。

バベルの塔にて -- こうした問題はどれも、コミュニケーションのために使われる状況でないのならば何の問題でもないだろう。もしもあなたのコンピューティングの仕事が、あなたのオフィスの中だけで、あなたのプリンタのみを使って、あなた自身の書類だけに関するものだったならば、何の支障も発生しないことだろう。けれども、クロス・プラットフォームの状況が絡んでくれば新たな問題が生まれ、さらにはもちろんインターネットの興隆によって状況は一気に深刻な段階に突入してしまった。ある日突然、さまざまに異なるシステムを使う人々が互いにメールを送り合い、互いにウェブページを読み合うことを始めてしまった。この事態に対処するためにさまざまな約束ごとが設けられたが、そういう約束ごとも、人々がそれを守りソフトウェアがそれに従う、という前提の下にしか成り立ち得ないものだった。差出人の名前が“=?iso-8859-1?Q?St=E9phane?=”のようなメールを受け取ったり、引用符が変な形の大文字の O のように見えるウェブページを見たりしたことがあるなら、それはこの種の問題がある形であなたの目前に現われた、ということなのだ。

また、フォントというものはインターネットで送られる性格のものではないのだから、特定のフォントに依存した文字は全く読めなくなる可能性もある。HTML では、私のページをあなたのマシンで読んだ時に特定の文字を特定のフォントで表示するように指定することもできるが、もしもあなたがそのフォントを持っていなかったら、そんな指定がいったい何の役に立つというのだろうか。

最後に、ここまでで触れなかったもう1つの大きな問題もある。それは、いくつかの言語システムにおいては、256 文字ではとても文字数が足りない、ということだ。一番はっきりした例は中国語で、この場合は何千もの文字がもともと必要なのだ。

そこで、ユニコードが登場する。

既得の土地、約束の土地 -- ユニコードの提唱することはごく単純なことだ。1つの文字をあらわすために使うバイト数を増やす、ということだ。例えば、文字あたり2バイトを使えば 65,536 個の文字が利用可能になる。これなら、ローマンアルファベットに加えてさまざまのアクセント付き文字や発音符付きの文字、さらにはギリシャ語、ロシア語、ヘブライ語、アラビア語、デーヴァナーガリー、それにアジアの各種言語での基本文字、その他多数、という範囲までの文字すべてを代表するに充分な数だ。

ユニコードの新しい点は、ただ各種の言語の文字を表現できるように文字コードを与えるということだけではない。それだけならば、既存の各種文字セットが(不満足な点はいくつもあるものの)すでに実現している。また、2バイト文字のシステムが使用できるというだけのことでもない。そのようなシステムはすでにアジアの言語用のシステムで実現されている。ユニコードが新しいのは、すべての言語のすべての文字を同時に含むような、統一された1つの文字セットを作る、ということなのだ。別の言葉で言えば、ユニコードの登場によって、システムやフォントの違いによる文字の食い違いが一切無くなる、ということだ。理論上では、1つの(巨大な)フォントを作ってそれが必要な文字すべてをことごとく含むようにすることさえも、不可能とは言い切れないだろう。

実際のところは、65,536 個の文字でさえも充分とは言えない。慣用的な書体とか歴史的筆記法などを考慮した学術的要請までも取り入れ始めれば、その数はいくらでも多くなり得る。(このような点を判断するにあたっては、ユニコードの標準を定めようと努力している人々の手元にはなかなか充分な情報が届いていないということだ。)そこで、最近になってユニコードはさらに文字数を増やして、65,536 個の文字セットを 16 セット、という範囲にまで拡張されることになった。(この拡張された分は“supplementary planes”と呼ばれている。)こうして、現時点ではほぼ百万文字が利用可能で、個々の文字は最大4バイトのメモリーデータによって表現されることになる。最初の supplementary plane は既にゴシック文字、音楽記号、数学記号、ミケーネ文明文字(Linear B)やエジプト象形文字などによって埋められている。文字標準の裁定に関わる今後の作業は、当然予想されることながら、さまざまの政治的、文化的、技術的、そして学術的な抗争を経てゆくことになるだろう。

<http://www.unicode.org/>
<http://www.unicode.org/unicode/standard/principles.html>

ここまで読んできて、それが自分にどんな関係があるのか、という疑問が浮かんだかもしれない。けれどもその答えは簡単だ。最初に述べた通り、もしもあなたが Mac OS X のユーザーならば、ユニコードはあなたのコンピュータの中に、現時点で、既に存在しているのだ。でも、存在しているって、いったいどこに? その質問に対する答えは、この記事の続編チェリーを2バイト - ユニコードと Mac OS X - その2で明かすことにしよう。


Retrospect 5.0 で Mac OS X のバックアップが可能に

文:Adam C. Engst <ace@tidbits.com>
訳:倉石毅雄 <takeo.kuraishi@attglobal.net>
訳:Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

バックアップを重視する人達にとっては、Dantz Development からの Retrospect 5.0 がリリースされていないことが Mac OS X へのアップグレードの一番の障害だったのだが(このトピックに関しては“今日はバックアップした?”シリーズの記事を参照して欲しい)、先週はそのリリースについて詳しく述べるスペースがなくなってしまった。

<http://db.tidbits.com/getbits.acgi?tbart=06758>(日本語)Retrospect 5.0、 Mac OS X をバックアップする
<http://db.tidbits.com/getbits.acgi?tbser=1041>(日本語)今日のバックアップはお済ですか? 第一部>(日本語)今日のバックアップはお済ですか? 第二部
(日本語)今日のバックアップはお済ですか? 第三部
(日本語)BackJack でインターネットバックアップ
(日本語)今日のバックアップはお済ですか? 第四部
(日本語)インターネットバックアップ戦略
(日本語)Ecrix 社製 VXA-1 テープドライブ:高速・大容量バックアップ

まず最初に、Retrospect 5.0 が出るまでなぜこんなに時間がかかったか、そして Mac OS X に完全に対応できるようにするのが想像以上に難しかったか、その理由を説明したいと思う。 Mac OS X では、言ってみれば、Apple は Unix オペレーティングシステムの上に古い Mac OS を接木したようなものだ。Apple はこの接ぎ合わせがユーザには見えないよう、かなりうまくやったが、 Retrospect のようにバックアップした通りにファイルを復元しなくてはいけないアプリケーションには、Mac OS と Unix がファイルを扱う上での相違はあまりにもはっきりしすぎている。Mac OS のファイルは Unix のファイルとは異なった性質と許可を有している。Mac OS ファイルは Unix ファイルにはないリソースフォークを持っていることもある。さらに、Mac OS ではリンクはエイリアスだけであるのに対して、Unix では数種類のリンクが使用できる。文字の大小の認識方法も異なる。

この相違のおかげで、Cocoa (そして Unix) は大抵の場合、Mac OS の性質やりソースフォークを認識せず、Classic アプリケーションは Unix 性質や、許可、リンクなどに対応できない。双方の橋渡しは Unix と Macintosh 双方のファイル情報を扱えるように特別に書かれた Carbon アプリケーションしかありえなかった。これに対処するため、Dantz はまず、プラグインを使用して Mac OS 9 用の Retrospect 4.3 で作動する無料の Retrospect Client for Mac OS X Preview をリリースして Mac OS X ベースの機器をバックアップできるようにした。これは裏技のようなもので、ちゃんと働いたが、理想的とは言い難いものだった。

<http://db.tidbits.com/getbits.acgi?tbart=06395>(日本語)Mac OS X 用 Retrospect Client パブリックベータ

オペレーティングシステムからのサポートも当然必要だった。バックアップからのちゃんと機能する Mac OS X インストールの復元を不可能にしていたバグを、Apple は 2001 年の 12 月末にリリースされた Mac OS X 10.1.2 でようやく直した。Dantz は即座に Mac OS X で作動して正しくバックアップと復元が可能な Retrospect 5.0 Preview を無料でリリースした。それから数ヶ月の間、Dantz は最終検査と包装を行い、先週ようやく Retrospect 5.0 のリリースに至った。これは Retrospect ユーザが慣れ親しんだ操作をほぼそのまま、Mac OS 9 だけでなく Mac OS X で(そして試してはいないが、Windows でも)使用可能にした。様々なオペレーティングシステム環境での根本的な互換性だけでなく、目に見えないところで Retrospect をさらにパワフルにするいくつかの変更点がある。これらの変更は二種類に分類できる:Retrospect のバックアップ機能の内部での変更と、Mac OS X のために必要な変更の二つだ。

<http://db.tidbits.com/getbits.acgi?tbart=06678>(日本語)Mac OS X 10.1.2 修正を盛りこむ
<http://db.tidbits.com/getbits.acgi?tbart=06687>(日本語)Macworld Expo San Francisco 2002 で見つけた珠玉たち

エンジンの馬力アップ -- Retrospect の内部変更のうち一番興味深いのは、Retrospect が File Backup Sets と呼ぶ外付けハードディスクへのバックアップの便利さをひどく制約していたデザインの削除だ。Retrospect の旧バージョンでは、バックアップされたファイルの名前を File Backup Set のリソースフォークに保存していた。しかし、リソースフォークは 16 MB 以上大きくなれないため、 File Backup Set に保存できるファイルの数はファイルの大きさに関係なく、60,000 から 75,000 の間に制約されていた。Retrospect 5.0 では、16 MB の上限に達したら、Retrospect が別の .cat ファイルを生成してカタログを保存する。これらの二つのファイルは同一のフォルダに保存されている必要があり、名前を変更してはいけない。

ホットスワップ可能な FireWire ハードディスクの値段が下がっていることもあり、この小さな変更はバックアップ専用メディアとしてのハードドライブの使用を簡略化してくれる。バックアップのスクリプトを作成するのに役立つ Retrospect の EasyScript 機能にもこのオプションがついてくる。例えば、80 GB ハードディスクを三つ、合計 700 ドル以下で買って、それぞれに File Backup Set を作り、順番に使用すれば、テープドライブシステムに負けないバックアップシステムが構築できる。400 ドルの 160 GB のドライブをいくつか使用すれば、もっとコストパフォーマンスが良い。後世のためにアーカイブするのも忘れてはいけない(最近、私は 1995 年から 1998 年のアーカイブから 400 MB 相当のソフトを復元する必要があった)。そのためにはドライブ機構をケースから取り外し、新しいのを入れて、古いのを何かの時のためにしまっておけば良い。三つのドライブを購入するより、Granite Digital の FireVue Hot-Swap Drive Systems を一つ買う方がさらに良い。これでは 230 ドルのケースを一つだけ買って、それぞれのドライブ用に 30 ドルのトレーを買ってケースから着脱する。試したことはないが、便利そうだ。

<http://www.granitedigital.com/catalog/pg26_firewireidehotswapdrive.htm>

オーディオやビデオを編集する場合には非常に大きなファイルを使用することが多いが、Retrospect 5.0 は 2 GB 以上のファイルをもバックアップが出来るようになった。この制約にぶつかる人は今までは少なかっただろう。だが、Retrospect 5.0 が Apple が現在使用している光学ドライブ全てをサポートできることを歓迎する人は多いだろう(完全な対応リストについては Dantz の Web サイトを参照して欲しい)。Apple は複数の製造元からのドライブを使用しているため、サポートの度合いは少しずつ異なる。ドライブのファームウェアの制約を避けるため、ドライブによっては、Dantz は CD-RW メディアではなく、CD-R メディアだけを使用するよう、制限している(それ以外の選択肢は全くサポートしないというものだった)。最後に、Advanced Driver Kit は高容量テープドライブには必要なくなった。

<http://www.dantz.com/index.php3?SCREEN=compatibility_list>
<http://www.dantz.com/index.php3?SCREEN=osx_apple_opt_compat_dev>

Mac OS X での変更 -- Retrospect 5.0 での大きな変更点は、明らかに、Mac OS X (10.1.2 以降) で走る点と、Mac OS X 10.1.2 以降で Retrospect Client を走らせている Mac で Mac OS X のファイルをバックアップできる点の二つだ。これらは大事なポイントだ。もし Mac OS 9 と Mac OS X をインストールしてある Mac を Mac OS 9 からブートした状態でバックアップした場合、Retrospect は Mac OS X ファイル許可にアクセスできない。ファイルをバックアップはするが、これらのファイルを復元しても正しく作動する Mac OS X システムの再現は出来ない。同じく、Retrospect Client を使用せずにマウントしたサーバからファイルをバックアップすることは出来るが、後の復元のためのファイル許可を保存は出来ない。

簡単に言えば、Mac OS X ファイルを正しく復元できるようにバックアップしたい場合は、Mac OS X がアクティブなオペレーティングシステムであるように、また、ネットワーク経由で Mac OS X マシンをバックアップする場合は、ただ単にサーバをマウントするのではなく、Retrospect Client を使用するよう、気をつけなくてはならない。

Retrospect Clients は Mac OS X 用に更新されたが(Mac OS 9 での Retrospect 5.0 Clients は Retrospect 4.3 Clients とバージョン番号以外は全く同一だ)、AppleTalk ではなく TCP/IP 経由でのみ作動する。ヒントを一つ:途中でバックアップを中断すると、Mac OS X Retrospect Client は作動していないのに使用中だと思い込むこともある。その場合は Off ボタンを Command を押しながらクリックしてストップし、On ボタンをクリックして再開する。(Retrospect Client をオフにしてオンにする)この技は Mac OS 9 でも働くが、その場合は普通に Off ボタンをクリックするだけで良い。

Dantz は Aqua をサポートできるよう、Retrospect のインターフェースを更新し、特定のファイルを保存するデフォルトセレクタを更新し、色々なファイルの場所を変更した(機能設定や記録は Library/Preferences/Retrospect に移り、カタログファイルはデフォルトで現ユーザの Documents フォルダに保存される)。Retrospect を自動的に起動するための Retro.Startup 機能拡張は Mac OS Xでは RetroRun と名前が変わり、 Library/StartupItems にインストールされる。誰も Mac OS X システムにログインしていなくても、RetroRun は自動的に Retrospect を起動できる。RetroRun でメモリのリークが報告されているが、近々更新されるだろうと思う(残念ながら、StartupItems フォルダから RetroRun を取り除いても長くは持たない。Retrospect の起動時に再生してしまうからだ)。

Retrospect 5.0 は Mac OS X マシンを完全に復元できる "Live Restore" 機能を提供している。もし起動可能な状態になければ、まずベースの Mac OS X システムをインストールし、復元するバージョンと同じになるところまでアップグレードし、Retrospect をインストールして、そして復元を行う。Live Restore をテストする機会はまだないのだが、これは重要だ。Mac OS X ファイル許可に関しては復元は少々難しいものがある。このトピックに関する Dantz Knowledgebase の記事を読んで緊急ではない状況で復元を試してみることを勧める。

<http://www.dantz.com/index.php3?SCREEN=knowledgebase_article&id=794>

もし選択の余地があるのならば、Retrospect を Mac OS 9 か Mac OS X のいずれで走らせるべきかは答を出しにくい。Dantz によれば、Mac OS X で走らせる利点の一つは Mac OS X の改善されたメモリ管理を活用して Retrospect が何十万ものファイルがあるボリュームをもバックアップできるという点だ(今までは、Retrospect はこれらのファイルをスキャンするだけでメモリ切れになることもあった)。また、Dantz は Mac OS X のマルチタスキング方法のおかげで Retrospect が Mac OS X のバックグランドタスクとしてもっと速く走ると述べている。これらにケチをつけるつもりはないが、非常事態でなければ、Mac OS 9 で作動している PowerPC ベースの Mac で Retrospect だけを走らせている方がもっと経済的で効率的な方法かもしれない。特に10 Mbps の遅いネットワークの場合、速い Mac を使用することによる優位は帳消しになってしまう。

ビジネスモデルの変化 -- Apple の Mac OS X への強行突入の結果として苦労を味わうことを余儀なくされた多くの会社たちのうちに Dantz が含まれていたことは、まったく疑問の余地がない。バックアップが重大な意味を持っている大きな会社組織のようなところが Dantz にとっての大口の顧客になるが、Mac OS X をめぐる不確実性はそうした大きな会社への Mac の売れ行きを停滞させてしまった。また、ただ Retrospect を Mac OS X で動くようにするということだけのために、Dantz は Apple と共に果てしない行ったり来たりの努力をはらわなければならなかった。このような事態の結果として、Dantz は電話でのサポートを有料化し、また Retrospect の異なるバージョンごとに違った料金設定をする、という変更に踏み切らざるを得なかった。

<http://www.dantz.com/index.php3?SCREEN=support_matrix>

現時点では4つの異なった Retrospect のバージョンがあり、それぞれ異なった機能を持ち、それぞれ異なった市場を対象にしている:

<http://www.dantz.com/index.php3?SCREEN=feature_comparison_mac>

Dantz からの直接購入の一番の利点はソフトウェアをダウンロードして直ちに使い始めることができる点だが、その代わり価格がほんの少し高めになる。例えば TidBITS スポンサーの Small Dog Electronics のようなところでは、特に Retrospect Workgroup と Retrospect Server についてはかなり安い価格を付けている。他のいろいろな業者では、Retrospect Express と Retrospect Desktop についても Dantz の価格よりは少し安くしているようだ。どの業者も今のところまだ Retrospect の実際の在庫は無いようだが、おそらく一・二週間以内には状況が変わるだろう。

<http://www.dantz.com/index.php3?SCREEN=quick_order>

フランス語版、ドイツ語版と日本語版は 2002年の第2四半期にリリースされる予定だ。国際ユーザーは現時点で英語版を購入して、ローカライズ版がリリースされた時点で対応するローカライズ版に無料でアップグレードすることができる。

第一印象 -- 私は Retrospect の、おもに Server 版を使ってみた。バックアップをテストするのは退屈なプロセスで、ことに私の 10 Mbps のワイヤーによる Ethernet やさらに遅い AirPort (AirMac) ネットワークで大量のデータを転送するのには時間のかかるものだったが、私はいくつかはっきりした感触を得ることができた。

第一に、最も重要なことだが、Retrospect 5.0 はほとんど Retrospect 4.3 とまったく同じに動作する。新しく覚えなければならないことは何もない。見かけ上は、以前と同じ機能が以前と同じに働く。Mac OS X の下では、時折 Retrospect が管理者パスワードを尋ねてくることになるし、また Aqua をサポートするためにインターフェイスの見かけがほんの少し変わったところもあるが、大きな違いは何も無いように見えた。

最初に起動した時、Retrospect は以前のバージョンからの設定を読み込むかどうかを尋ねてくる。この読み込みは問題なく働いたようだ。ただし、もしも Retrospect に何か問題が起こったとして、それに対処するトラブルシューティングをしようという場合には、私ならまずは設定無しのフレッシュスタートから試してみるだろう。なぜなら、データが微妙に壊れてしまう可能性は、前バージョンからの設定の読み込みから発生することが多いと思えるからだ。

実際のところは、私や何人かの他の人たちは internal consistency check エラーを経験していて、Dantz がこのエラーの原因を特定するための手伝いをしようと、私たちはさまざまなトラブルシューティングを繰り返していたのだ。私はまた Retrospect がバックアップ中に Mac がクラッシュするという状況もいくつか経験した。ただ、これらのクラッシュが直接 Retrospect によるものかどうかの特定はできなかったが。さらに、TidBITS 編集者の Jeff Carlson は、Retrospect が彼のパーティションのうち1つについて、バックアップはできても比較操作を拒否してしまうのを経験している。幸いなことに、何年にもわたって Retrospect を使ってきた私たちの経験を通じて、こうしたバグによってバックアップしたデータが失われたことは一度もない。

<http://support.dantz.com/ubbthreads/showflat.php?Cat=&Board=Desktopworkgrupx&Number=2630>

こう書いてくると何か恐ろしそうに聞こえるかもしれないし、私だって問題が起こらないに越したことはないとは思うが、Retrospect を何年も使ってきた経験から言わせてもらうと、こういうことはいわばデジタル炭鉱の中の電子カナリアなのだ。この例えがピンとこない方のために解説を加えると、炭鉱の坑夫たちは坑道に入る際、カナリアを連れて行ったものだ。これは、もしも有毒ガスが坑道に充満していればまずカナリアが気絶するため、坑夫たちがいち早くそれに気付いて脱出できるようにするためなのだ。Retrospect の動作は、標準ではない保存デバイスに向かって可能な限り高速に大量のデータを送り込み、かつただの1ビットもデータが失われることのないようにしなければならないので、すべてがうまく行っているように見えるにもかかわらず Retrospect がエラーを報告するということはあり得ないことではないのだ。ある友人から聞いた話では、ある大きな会社が Cisco ルータを新しいファームウェアにアップグレードした時、実はその新しいファームウェアにはバグがあって百万回に一回の割合でパケットが失われていたという。そのバグはずっと気付かれずにいたのだが、ある時 Retrospect がエラーを報告し始めるようになって初めて発見されたということだ。百万回に一回というのは非常に稀なことのように聞こえるだろうが、何ギガバイトものデータをバックアップしている際には、積み重なって現実の問題として表面化する、というわけだ。

最後に強調しておきたいことは、慎重を旨とする多くのユーザー(私も含めて)にとっては、この Retrospect 5.0 のリリースこそが、自分のメインマシンをMac OS X にアップグレードできるゴーサインになっている、ということだ。確かに、他のいろいろのバックアッププログラムも過去数ヵ月間にいろいろ登場してきた。例えば FWB の BackUp ToolKit(Tri-Edre の Tri-Backup と同じもの)とか Qdea の Synchronize Pro X、Randall Voth の Synk、CMS Peripherals の Automatic Backup System、それに PSoft の iMsafe などが挙げられるだろう。これらのユーティリティはいずれも、個人ユーザーがデスクトップにマウントしたメディアの中にデータをバックアップするような用途に適している。(テープドライブには使えない。)それに対して、複数台の Mac を任意のメディアに、例えば大容量のテープドライブなどにバックアップするような用途に使え、しかもアーカイブ化を提供し、かつリソースフォーク、HFS+ のメタデータ、Unix のパーミッションとグループオーナー、ファイルのハードリンクなどをすべて保ってくれるようなユーティリティは、Mac の上では Retrospect 5.0 が唯一の選択肢なのだ。

<http://www.fwb.com/cs/btk/main.html>
<http://www.qdea.com/pages/pages-sprox/sprox1.html>
<http://mypage.uniserve.ca/~rvoth/synkx.html>
<http://www.cmsproducts.com/products/abs.htm>
<http://homepage.mac.com/iMsafe/>


tb_badge_trans-jp2

非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

Valid XHTML 1.0! , Let iCab smile , Another HTML-lint gateway 日本語版最終更新:2005年 12月 26日 月曜日, S. HOSOKAWA