TidBITS#686/30-Jun-03 TidBITS#686/30-Jun-03ハードディスクの最適化に時間を費やす前に、それがなぜ無駄であるのかDavid Shayer の記事を読んでみよう。また今週は Adam が MacHack を取材し、この会議の人々やイベント、服装などの逸話をまとめた。さらに、本年のApple Design Awards の受賞作品を報告する。その他 Mac OS X 移行者の数を訂正、Extensis による DiamondSoft の買収、Casady & Greene の廃業、ドイツ語翻訳者募集。
記事：
Copyright 2005 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: editors@tidbits.com>
本号の TidBITS のスポンサーは：
読者のみなさん! あなたのカンパで TidBITS を応援してみませんか？
<http://www.tidbits.com/about/support/contributors.html>
今週はKen Workman氏、Robbie Brown氏, そして
Michael Tsai氏の暖かい支援に感謝!
<http://www.tidbits.com/about/support/contributors.html>
SMALL DOG ELECTRONICS: PowerBooks with AppleCare On Sale!
PowerBook G4/867 w/ SuperDrive: $1645! | With AppleCare: $1919!
PowerBook G4/1 GHz 17-inch: $3079! | With AppleCare: $3349!
Visit: <http://www.smalldog.com/tb/> 802-496-7171
SIX DEGREES from CREO: Timefreeing technology that automatically
links the messages, files and people involved in your projects.
Works with Microsoft Entourage and Outlook. Free trial version!
========> <http://www.creo.com/sixdegrees/index.asp?id=tidbits>
Casady & Greene が閉店 -- Casady Greene は、Macintosh 市場で最古参の会社だが、その 19年の歴史を畳んだ。これは Casady & Greene 社広報担当副社長の Bonnie Mitchell からの話により、締め切り間際で詳細は不明だが、Casady & Greene は財務的に生き残れなくなっているようだ。この会社は、今年になって、Spell Catcher X, Tri-Catalog, Clone X, iData Pro ( TidBITS-675 の「デジタル下駄箱：: iDataPro X 1.0.5」参照) など、かなりの Mac OS X ソフトウェアを出しているが、営業を続け、専属契約プログラマーに金を払い続けるほどの利益に達していない。Casady Greene 社の現在の製品には、かつての Conflict Catcher (Mac OS X 版は出ず) や SoundJam (Apple iTunes のベースになった) のように広くアピールするものがない。そして、Mac OS X への移行はこの会社にとってとりわけ逆風となった。[ACE]（細川）
<http://www.casadyg.com/>
<http://db.tidbits.com/getbits.acgi?tbart=07145>
(日本語)デジタル下駄箱：iDataPro X 1.0.5
Extensis が DiamondSoft を買収 -- Apple が Mac OS X 10.3 Pantherでフォント管理ユーティリティ Font Book があることを明らかにしたほんの数日後に、Extensis (Suitcase の製造元) は DiamondSoft (Font Reserve の製造元) の買収をアナウンスした。偶然だろうか？ そう偶然なのだ。実際のところ、企業の買収はほんの数日でまとめられるものではない。Extensis のNicole Andergard の言によれば、この買収は時間を掛けて進められ、Font Book のアナウンスは両社にとっても寝耳に水だった。また、この買収の真の目的は、クライアントサイドでの Suitcase の強みを、Font Reserve のサーバーサイドの能力と融合して、最終的に最も強力なフォント管理ソリューションを出版業界のプロフェッショナルに提供することだ。Apple は Font Bookについて詳細の多くをまだ明らかにしていないが、Nicole の言によれば、Font Book は 初級レベルのフォント管理プログラムのようで、Suitcase からプロフェッショナルユーザーの客を奪うことはないだろうと確信している。[ACE]（細川）
<http://www.extensis.com/press/releases/063003_fr.html>
<http://db.tidbits.com/getbits.acgi?tbart=06751>(日本語)Font Reserve が Mac OS X に
<http://db.tidbits.com/getbits.acgi?tbart=06797>(日本語)Suitcase 10 で旅してみる
Remember? は健在 -- Dave Warker の Remember? は、その見事なシンプルさが美しい、カレンダー兼リマインダーのアプリケーションだ。誕生当初はデスクアクセサリとして出発したのだが、今回バージョン 4 に至って、ついに Mac OS X への移行を果たした。Remember? はカレンダーの中に複数日にまたがるイベントをバナーとして表示することはできないが、その素晴しいオリジナルなインターフェイスと、柔軟性に富んだリマインダーのおかげで、iCal の立派な好敵手と呼びたくなる。 $20 のシェアウェアだが、この値段なら掘出し物だ。[MAN]（永田）
<http://www.warker.com/remember.html>
Jaguar にアップグレードしたユーザー数について訂正 -- 先週号で、私は MacHack の会場で開発者の面々にどの程度の Mac OS X ユーザーが Mac OS X 10.1 から Jaguar へのアップグレードをしないでいるのかと尋ね、ある人からかなりのパーセンテージのユーザーがアップグレードしていないという返事を聞いて驚いた、と書いた。実は、私の驚きには根拠があったのだ。つまり、私は単に間違った数字を聞いてしまっただけだった。（その人が釈明してくれた通り、不眠不休の MacHack が終わってから 48 時間以内に聞いたことは信用しては駄目、ということだ。）実際の数字はこうだ。その開発者のユーザーたちのうち 75% ほどは Mac OS X を使っており、そのうち今でも Mac OS X 10.1 を使っているのはたった 1% ほどに過ぎない。別の開発者で、やはりその人のソフトウェアもユーザーのシステムバージョンを報告する機能を持っているのだが、その人に聞いた数字もほとんど同じパーセンテージだった。だから、実際に現状で Mac OS X 10.1 を走らせているユーザーの数は非常に少数だと言っても間違いのないところだろうと思う。
ただし、これらの数字を解釈する際には、いくつか注意しておかなければならないことがある。まず第一に、これらの数字は自動的に収集されたデータであるには違いないが、その情報を送るかどうかの選択は個々のユーザーに任されているのだ。だから、古いバージョンの Mac OS X を走らせている人ほどそう簡単には情報を開示したがらない人が多いということも充分考えられるだろう。第二に、そしてこちらの方がより影響が大きいと思われるが、これらの数字はその時点でソフトウェア製品を購入して登録した人々からのみ届いた情報だということだ。つまり、そういう人々は、どちらかと言えば常に最新のオペレーティングシステムにアップグレードし続けたいと思うような人々が多いと考えるのが自然だろう。つまり、わざわざお金を払って Jaguar にアップデートなどしたくない、と思うような人々は、傾向としてそう頻繁にはシェアウェアの登録もしないだろう、ということだ。[ACE]（永田）
Apple が Design Awards 2003 を発表 -- 先週の Worldwide Developer Conference (WWDC) の締めくくりに、Apple は本年の Apple Design Awardsの受賞作品を発表した。昨年と同様、この賞は、7つの部門で卓越した Mac OS X ソフトウェアに与えられるものだ。トップに輝くのは 2つの部門を受賞したSalling Software の Salling Clicker 1.5 で、Best Mac OS X Product (最優秀賞) と Most Innovative Mac OS X Product を獲得した。このソフトはBluetooth ネットワークを使用して、特定モデルの Sony-Ericsson 携帯電話から 自分の Mac にある iTunes や Keynotcan などスクリプト実行可能なアプリケーションをコントロールできる。特に秀逸なのは、“proximity sensor”スクリプト（接近センサ）で、携帯電話が Mac の Bluetooth 交信範囲内に入るとこのスクリプトが作動する。
<http://developer.apple.com/wwdc/designawards.html>
<http://db.tidbits.com/getbits.acgi?tbart=06818>(日本語)2002 Design Award の受賞者を発表
<http://homepage.mac.com/jonassalling/Shareware/Clicker/>
Best Mac OS X User Experience 部門は Space Holdings の Starry Night Backyard 4.0 (TidBITS-542 の「Starry Night Backyard とともに天高く」参照)だ。Best Mac OS X Technology Adoption は Software MacKiev のWorld Book 2003 Jaguar Edition が受賞した。 真のコラボレーションツールにふさわしい共同作業により、ミュンヘン工科大学の Martin Ott, Martin Pittenauer, Dominik Wagner, Ulrich Bauer らは Hydra 1.0.1 で Best Mac OS X Student Project 部門を受賞した。これは Rendezvousを利用するテキストエディタで複数のユーザーがひとつの共有文書にアクセスして編集できる。(Adam と他の約10名の参加者は MacHack で Hydra を使い、今年の Hack Contest のもようを取材した。) 今年の Best Mac OS X Use of Open Sourceはミシガン大学の Fugu 1.0 で、これは SFTP (Secure File Transfer) のグラフィカル・フロントエンドだ。そして本年の新しい部門 Best Mac OS X Server Solution は BioTeam の iNquiry 1.0 が受賞した。これは複数の Mac OS X Server マシンにロードするソフトウェアで、プロセシング・クラスターを形成して生物学的データを処理できる(TidBITS-622 の「バイオインフォマティクスと Mac」参照)。受賞者の方々おめでとう。また各部門で次点になったソフトウェアも素晴らしいものだ。これらのソフトは Apple のウェブサイトにリスとされている。 [JLC]（細川）
<http://www.starrynight.com/>
<http://db.tidbits.com/getbits.acgi?tbart=06069>
(日本語)Starry Night Backyard とともに天高く
<http://www.mackiev.com/>
<http://hydra.globalse.org/>
<http://db.tidbits.com/getbits.acgi?tbart=07244>(日本語)MacHack の 2003 年度ベスト・ハック・コンテスト
<http://rsug.itd.umich.edu/software/fugu/>
<http://www.bioteam.net/>
<http://db.tidbits.com/getbits.acgi?tbart=06764>(日本語)バイオインフォマティクスと Mac
ドイツ語翻訳者急募 我々のドイツ語版翻訳チームは縮小し人員的にも時間的にも余裕が無くなってきている。そのようなわけで、いましばらくTidBITS を翻訳公開することができない。(日本語、オランダ語、フランス語翻訳チームはまだ頑張っている。スペイン語、ロシア語は新しい翻訳チームを作る必要がある) もしあなたが、毎週僅かな時間を割いて TidBITS をドイツ語に翻訳して貰えるなら、または一緒になって仕上げるのを手伝って貰えるなら(翻訳は苦手だがドイツ語の編集は可能な方)、ドイツ語 Macintosh コミュニティの人々はあなたに感謝します。詳細は Heinz Gnehm <[email protected]> までお問い合わせください。どうかお助けを！[ACE]（日本語チームにもお助けを：細川）
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Macintosh 関係のカンファレンスが終了すると、たいてい私は自分がその場に出席して他の参加者たちから、その場の議論から、一般会衆から、その他いろいろな形で感じ取ったことが、はたして Macintosh の世界というものに全般的にどのような教訓を与えてくれるのか、という風に何らかの結論を引き出すのが常だった。けれども今年の MacHack を終えてみて、私はそういう風に何か言うべきことをあまり思いつかないことに気がついた。これは、Apple が Worldwide Developer Conference (WWDC) の日程を変更して MacHack の終了したすぐ１日後から始まるようにしてしまったことが大きな要因だろう。その結果、MacHack の会場で開発者たちは、その年の WWDC で何が発表されるのかをただ推測するしかなかったし、さらに悪いことには MacHack にはもはや Apple Feedback セッションを設けることができず、MacHack に来た Apple 社員の人数も、普段は 15 人前後は来てくれていたのが、今年はほんの数えるほどしかいなかったからだ。（全体の出席者数の減少度は 20% 以下にとどまった。これは、WWDC との衝突を考えれば驚くほど力づけられる数字だと思う。）当然ながら、ほとんどすべてのハックは Mac OS X を使っており、まだ Mac OS 9 を使っている人を見つけること自体がひと苦労、という状態だったが、もはやそのことから今さら教訓を得るというほどのことでもない。結局、今年の MacHack では Macintosh に焦点を合わせるということ自体がやや印象として薄れた感が残り、また、私が漏れ聞いた感想によれば、全般的なセッションや論文のレベルはかなり高かった、と言える程度のようだ。特に楽しかったものと言えば（全体を代表するものとはとても言えないが）昨年の“Mac OS 9 は死んだ！”セッションを再現してみせた Keith Stattenfield のセッションで、彼は Mac OS 9 が人々にとってどれだけ大きな意味を持っているか、どれほど多くの人々がまだ Mac OS 9 を使い続けているか、ということを感動的に語った挙句に、“Mac OS 9 は _まだ_ 死んでる！”と叫び、続けざまに４つか５つのスライドで「死んでる」という文字を変形させたものを掲げてみせた。
実際のところ、主催者たちは来年に向けてカンファレンスの興味の範囲が拡大しつつあるという事実を反映させることを決定し、来年はカンファレンスの名前を Advanced Developers Hands On Conference (ADHOC) として、Unix や Palm、その他のプラットフォームを扱ったセッションも加えていくことを発表した。ハック・コンテストも、過去 17 年間にわたってこれを運営してきた人々の興味が別の分野に移っていくことを反映して微妙な変化をしていくことは避けられないだろう。ただ、いくら名前が変わって範囲が拡張するとしても、私は基本的な感覚そのものはそれほど変わらないだろう、ということに確信がある。なぜなら、業界の他のどのカンファレンスとも異なって、ここでのセッションや論文投稿、その他のイベントを運営している人たち自身が、長年出席し続けている人たちだからだ。何よりも第一に、（ゲティスバーグの演説を言い替えさせてもらえば）これはソフトウェア開発者の、開発者のための、開発者によるカンファレンスだからだ。来年の ADHOC は、今のところ 2004 年の 7 月 21 日から 24 日までという予定になっているが、これは他のトレードショウとの衝突を避けるために変更されるかも知れない。
さて、遠くを見据えた教訓を探すのはやめて、今回は MacHack の会場で私自身が何を体験したか、そのこぼれ話をいくつか、紹介してみたい。それぞれの話に関係した舞台裏の写真もいくつかあるので、このリンクでどうぞご覧あれ：
<http://www.tidbits.com/resources/686/machack-2003.html>
ジャンプスーツの一週間 -- 数年前に MacHack でキーノートのスピーチをして以来、Andy Ihnatko は私と同様 MacHack の魅力に取りつかれ、以来毎年参加している。けれども去年、彼は非公式の「一番古い t-シャツ」コンテストのことを聞きそびれて参加できなかったのがよほど悔しかったのだろう、geek としての誇りを賭けて、今年の彼は MacHack を「ジャンプスーツの一週間」だと宣言し、毎日違ったスタイリッシュなジャンプスーツに身を包んで現われた。初日の彼は Wingz のジャンプスーツを着こなして登場した。これは Wingz のスプレッドシートが Macworld Expo で話題独占のデビューをした Mac 初期の時代に敬意を表してのものだ、次の日は、Yankee Point 3 原子力発電所の技術者たちが着ていたジャンプスーツだった。（これは廃品利用店で購入し、放射能汚染されていないか友人に調べてもらったものだという。）そして三日目には、Challenger 以前の時代の本物のスペースシャトル乗組員用フライトスーツで、ちゃんと NASA とシャトルのワッペンまで付いていた。
大ニュース！ 携帯電話は小さすぎる！ -- Real Networks で RealOne Player の仕事をしている Greg Robbins は、私たちがワシントン州に住んでいた頃わが家からほんの数マイルのワシントン州 Issaquah に住んでいたのだが、今回彼は MacHack 会場に到着して間もなく、鞄の中に彼の携帯電話が見つからないことに気付いた。数分間探してもまだ見つからなかったので、私は自分の携帯電話から電話をかけてみた。呼び出し音が鳴ったので、彼の携帯電話がまだ鞄の近くにあることははっきりした。けれども、Greg がいくら探してもなかなか見つからない。もう一度呼び出してみて、やっと見つかった。彼の鞄から転がり出て、ホテルのロビーの室内花壇のプランターの中に落ちていたのだ。携帯電話がこれ以上小さくなるようなら、われわれは皆、このやっかいな代物をベルトに取り付けておくだけでは足りずに、ちゃんと自分の体に取り付けなければならない時代が来るんじゃないだろうか。
別れ道 - その時あなたは -- ヨギ・ベラの有名なセリフがある。道路の別れ道 (fork) に来たら、拾えばいいのさ！（フォークを。）ヨギはきっと、フォークをたどって歩くとどこへ行き着くのか（もちろん、食事中の人の口の中だ）考えもしなかったのだろう。でも、Runtime Revolution で働いている Geoff Canyon は私と一緒に道を歩いていて、本物のフォークが落ちているのを見つけた。これは珍しい、ということで私たちはこれを拾った。いや、取った。いやそうじゃない、写真を撮った。まあとにかく、MacHack 会場のこんな近くにフォークが落ちている、ということは、これは実は code fork（プログラミングコードの分岐）なんじゃないか、と Geoff と私は思ったものだ。
<http://www.inspiredlogic.com/>
<http://www.runrev.com/>
深夜は軽口の時間 -- 今までに聞いたことのないような Apple や General Magic の社内の裏話でいっぱいの Scott Knaster の第二キーノートの後、大勢の人々が会議室の一つを占拠して、その場は非公式なポートワインとスコッチウイスキーの味比べの場と化した。（自分のための覚書： ミシガン州 Dearborn のホテルとくれば、ちょっと車で買い物できるくらいの距離にはまともなポートワインを売っている店は無いものと覚悟すべきだ。）Palm Desktop for the Mac の仕事をしている Chris Page も、ちょっとした食料を持参してきていた。彼が取り出したアーモンドタルト (Almond Tartlets) は、すぐにそのフランス語っぽい語感からちょっとアブナイ冗談を喚起することになった。（この時点で午前 3 時を過ぎていたのでお許しあれ。）そこで Chris は袋に手を差し込んで、次の品物を取り出していわく、「さてお次は一箱の、ダブルアンタン (double entendres)！」本当に飲み物を肺に吸い込んでしまった人はいなかったと思うが、みんなバカみたいに笑い転げてしまったので、危ないところだった人は何人かいた。
<http://www.chris-page.org/>
<http://www.palm.com/us/software/desktop/mac.html>
家族で仲良くハッキング... -- Default Folder の著者である Jon Gotow と、15 歳になる彼の息子 Ben とは、MacHack の期間中ほとんどずっと離れずに一緒にいて、コンテストで優勝した彼らのハック、Unstoppable Progress の製作に励んでいた。（TidBITS-685 の記事“MacHack の 2003 年度ベスト・ハック・コンテスト”を参照。）MacHack においては、テクノロジーそのものが高度に社交的な意義を果たしているだけでなく、何と、ティーンエイジャーたちが率先して自分の親と一緒に過ごしたがる、という意義さえ持っているのだ。まあ、少なくともそういうティーンエイジャーがいた、ということだ。ただし、私が MacHack 会場で会った子供たちは、平均的な子供たちよりはずっと順応性が高いように見えたのは確かだが。
<http://www.stclairsoftware.com/DefaultFolderX/>
<http://db.tidbits.com/getbits.acgi?tbart=07244>
(日本語)MacHack の 2003 年度ベスト・ハック・コンテスト
MacHack 料理 -- 何年も MacHack に出席し続けてきて、やっと私はここでの途方もない食事の時間と、カンファレンス中に満ち溢れているプログラマー用ジャンクフードとに対処するための素晴しい解決策を思いついた。家を出て空港へ行く途中、私は食料品店に立ち寄って、最高においしそうな Braeburn 種のりんごを８個、買っておいたのだ。これで、私は毎朝、「朝食」としておいしいりんごを１個ずつ、食べることができる。「朝食」と言っても、これはホテルが出してくれる「ランチ」、つまり事実上たいていの参加者が毎日の最初の食事にしているもの、を食べる前、という意味に過ぎない。皆さんがどうかは知らないが、私は目を覚ましてすぐにたっぷりの温かい食事を食べる気にはどうしてもなれない。でも、この１個のりんごのおかげで、私の胃袋はホテルの食事をちゃんとその日の二度目の食事だと錯覚して、受け入れてくれるようになった。その後は、何やかやのスナック類と、深夜の角型ピザ、と続き、最後の締めとして、その日の二度目のりんごが、健康的な食料で一日を終わらせてくれるのだ。本当に効き目があるか、証拠を見せろって？ 何よりの証拠は、私が自分の袋からりんごを１個取り出すたびに、必ず誰かがうらやましそうな顔をしてそれを見つめながら、どこで買ったんだい、と聞いてきたのだ。まあ、これはわれわれが皆年をとった、ということを意味しているに過ぎないのかも知れないが。
実際、今年は料理が良くて普通のホテルの標準よりはかなり立派なものだった。これは、カンファレンスの主催者がホテルのシェフたちに申し入れて、MacHack の参加者たちは皆食事に対しては大胆だから、と念を押してくれたかららしい。最初の日のランチはメキシコ料理がテーマで、高級な料理（あるいは真正のメキシコ料理）ではなかったかも知れないが、チキンかサーモンかだけを選べるライスピラフで「何だ、またこんなのか」とため息しか出ないようなものと比べればずっとずっと質の良いものだった。二日目のランチはロシア風と、何となく北ヨーロッパ風との間を行き交うようなもので、やはり私が目覚めて一時間以内に進んで食べたくなるようなものではなかったが、それでも少なくとも目新らしさだけは十分にあった。
シェフの一人は、これがまたユニークな人で、すいかで作ったフルーツサラダのボウルにりんごの形をくりぬいたり、「死の回転ピザ」に似せたクッキーを焼くのを手伝ってくれたりした。このクッキーを共同製作した Maurita Plouff は、そのお礼に専門家たちに頼んで、このシェフがシェフ・コンテストに応募する時に使うマルチメディア・ビジネスカードを作り上げるのを手伝ってあげたのだった。
ファイル共有はまだまだ厄介 -- 驚くべきことがある。過去十年間にさまざまの技術が進歩してきたにもかかわらず、コンピュータから別のコンピュータへとファイルを移す作業は、依然として必要以上の困難を伴っているのだ。MacHack の内部ネットワークは、どうやらスイッチ部の不良部品が原因と思われる問題に付きまとわれており、その結果、TCP/IP ネットワークのリソースを便利に表示できるはずの Rendezvous も、共有先のコンピュータをいつも表示できるとは限らなかった。さらに、ユーザー側のミスによる問題も重なった。ファイル共有をオンにするのを忘れている人や、何らかの理由で自分の Drop Box フォルダのパーミッションを不正に設定している人、その他いろいろの問題が起こった。ある場合には、“Computer to Computer”ネットワークに切り替えることで問題が解消された。（この“Computer to Computer”というのは特定目的 (ad hoc) ネットワークに Apple が付けた名前で、まさしくこのカンファレンスの将来の名前 (ADHOC) と共通点のあることがふさわしい。）とにかく要点をまとめれば、ファイル共有はいつも少しずつ改良されつつあるが、それでもまだまだ改善の余地がある、ということだ。
Hulk をぶっ潰せ -- 最後に、授賞式後のパーティーの後で、われわれは皆この夏の新作映画、The Hulk を観に行った。何とまあ、すごい悪悪映画だ。観るに値する悪映画、つまり観ていて楽しいことは楽しいのだが A Mighty Wind（フォーク音楽版の Spinal Tap というところか - でも Spinal Tap ほど可笑しいところはほとんど無いが）とか Bend It Like Beckham（これはインド人の少女がイングランドでサッカー選手になるというとても楽しい映画）を観ている時のような感覚がまったく無くてちょっと後悔の念が疼くという種類の映画、でさえもなかった。そう、この The Hulk は本当にただの悪い映画で、マンガ本のファンはイライラさせられ、その他の観客は混乱するだけだ。たぶんその原因は Hulk が脚本を覗き込んで「Hulk、筋書潰す。弱弱人間、アホアホ映画作る。」なんてつぶやくあたりの訳のわからなさから来ているところが大きいだろう。MacHack 伝統の“Keith は説明する”の集まりで、皆で首をひねりながら、あの映画は一体何だったんだ、と知恵を絞り合った。（この集まりは、Apple の Keith Stattenfield を囲んでわれわれ皆が集まり、あらゆる細々した詳細を検討しつつ実際あの映画の表面に現われているよりももっとたくさんのユーモアを掘り起こそうというものだった。）この The Hulk という映画のベストシーンはどこか、という議論もちょっとあって、それは Marvel Comics の Stan Lee と Lou Ferrigno（彼は何年も前にテレビで Hulk を演じた）が警備員役で映画のはじめの方にちょっと顔を出した所、という声も挙がった。いやいやこの映画そのものが単に Tomb Raider II の予告編に過ぎないのさ、という声もあった。Tomb Raider II の方は、同じ悪映画でも、観ていてずっと楽しいものになるだろうから、と。
<http://keithexplains.com/>
<http://www.thehulk.com/>
<http://amightywindonline.warnerbros.com/>
<http://www.foxsearchlight.com/bendit/>
<http://www.tombraidermovie.com/>
文： David Shayer <[email protected]>
訳： 亀岡孝仁 <takkameoka@earthlink.net>
訳： 佐藤浩一 <koichis@anet.ne.jp>
ディスクを最適化するのは時間の無駄である。と私は言う。秘密は暴露されてしまったのである。ではなぜあれほど沢山の人が、最適化ツールはどの Macユーザーの道具箱にも欠かせないツールの一つであると信じているのか？それに、そもそもディスクを最適化するとはいったい何を意味するのか？
見えないところで進むフラグメント -- ファイルをディスクに保存する時、ファイルシステムはそのデータを書き込むための空きスペースを探す。その保存に必要なだけ十分に大きい一つのスペースが無い場合、ファイルをいくつかの小さなスペースに分けて収納する。一つのファイルが一つ以上の部分に分けて保存された時、それをフラグメント化されたと呼ぶ。この一つの部分がフラグメント、或いはエクステントと呼ばれる。
一つのファイルは二つのフラグメントに分解されることもあるし、20 フラグメント、或いは 200 フラグメントかもしれない；システムはいかなる数のフラグメントも同じ様に問題無く扱える。しかしながら、フラグメント化されたファイルを読むには、フラグメント化されていない一つのファイルを読むのより長い時間を要する。それは、ハードディスクのヘッドは個々のフラグメントの所に行きそれを個別に読み取らなければならないからである。一塊のデータを、そしてそれがかなり大きな場合でも、順に読んでいくのは速い。しかし、トラックからトラックへとヘッドを動かしながらフラグメントを辿っていくのは比較的遅い。（"比較的" とは - 数ミリセカンド余分にかかるというレベルである。）
この速度低下に対する解は？デフラグメント化あるいは最適化である。あるプログラムはディスクをデフラグメント化すると言い、他のプログラムではディスクを最適化すると言い、両方やると言っているのもいくつかある。では、その違いは何か？
デフラグメント化とは複数のフラグメントに分解されているファイルを一つのフラグメントに統合する事である。ファイルをデフラグメント化する事は問題の一部分でしかない。と言うのも、ディスク上の空きスペースはともすると多くの部分に分かれているからである、ここにちょっと、あちらにちょっとと言った具合に。事実、空きスペースはフラグメント化されているのである。5 GB の空きスペースがあったとしても、それは 5,000 個の 1 MB の塊を意味しているかもしれない。次にセーブするファイルはフラグメント化されるかもしれない、単純にフラグメント化していない十分な大きさの空きスペースが無いだけの理由で。そこで最適化が登場するのである - それはフラグメント化されたファイル _そして_ 空きスペースすべてをデフラグメント化するのである。
いくつかの最適化ツールは似たようなファイルを、例えばすべてのオペレーティングシステムファイルを、物理的に隣り合うよう配置する。こうする事によってコンピュータの速度アップが進むとしている。なぜならばオペレーティングシステムのファイルは一緒にアクセスされる可能性が高いので、こうする事でディスクヘッドが次のファイルを読みにいく時長い距離を移動する必要をなくするからだと。この考え方は一見良いように見えるが、私にはこの技術で、かすかにでも目に見えるだけの速度向上が見られるとは到底思えない。非常に単純な場合を除いては、コンピュータが次に必要とするファイルはどれかを事前に予測するのは大変困難な事だからである。
でも、ディスクを最適化すれば Mac はより早く動くはずだ？ええ、多分。しょっちゅう使うファイルがフラグメント化していた場合、例えばオペレーティングシステムの鍵となる一部分とかが、そのファイルをデフラグメント化してやる事は役に立つであろう。しかしながら、オペレーティングシステムというはそもそもディスクが新たにフォーマットされた直後に書き込まれる。ディスクは空であるので、オペレーティングシステムは殆んどフラグメント化しないのである。もし、たまにしか使わないファイルがフラグメント化していた場合、例えば Ethel 叔母さんの誕生パーティの QuickTime ムービーのような、そのファイルに普通にアクセス出来る限り - この場合ムービーが再生できる - 問題ではないのである。結論を言えば、フラグメント化を避けるというのはそのファイルが常にアクセスされる場合にだけ役立つのである。
それではこのディスク最適化という信仰はどこからきたのであろうか？昔に遡って Windows の初期の頃、そしてその前の DOS 時代、PC は FAT (File Allocation Table) と呼ばれるファイルシステムを使っていた。この FATファイルシステムはファイルをフラグメント化しやすいという伝統を持ち、従ってディスクは急速にフラグメントだらけとなってしまった。当時、ディスクは、そしてコンピュータ全般に、今日の標準に比べれば非常に遅かった。このような痛々しいほど遅いディスクとコンピュータの場合、ディスクを最適化するというのは目に見えるほどの性能改善となり得たのである。近代のコンピュータ及びディスクは、勿論比べものにならないほど速いし、そしてずっと容量の大きいそしてもっと優れたディスクキャッシュを持っており、このどれもがフラグメント化されたディスクの影響を著しく小さくしている。
Apple が Mac 用に HFS (Hierarchical File System) ファイルシステムを設計した時、そしてその後 HFS を HFS+ に置き換えたが、フラグメント化を最小にするための特別の配慮を行なった。すべてのハードディスクは、セクタと呼ばれる 512 byte の塊でデータを保存する。FAT, HFS, そして HFS+ はもっと大きな塊を使うが、FAT ではクラスタと呼ばれ、HFS ではアロケーションブロックと呼ばれる。クラスタやアロケーションブロックの目的の一つは、ファイルをより大きな部分として収納することでフラグメント化を減らす事にある。しかし HFS はもう一歩先までやる。ファイルをディスクに保存する時に、フラグメント化を更に減らすために、Mac ファイルシステムは更に大きなクランプと呼ばれる塊でスペースを管理する。
Mac ファイルシステムがファイルを保存しようとする時、まず全ファイルを収納できるに十分な一つの空きスペースを探す。それが見当たらない場合、利用可能な一番大きな空きスペースを選び、次に二番目に大きな、そしてその次、というように可能な限りフラグメント化を防ぐ努力をする。HFS は回避可能な場合は絶対にファイルをフラグメント化しない。
実世界のフラグメント化 -- 多くの人にとって、ディスクがフラグメント化するのは次の二つである：満杯のディスクとメール。
一般的に、Mac の HFS+ ファイルシステムはフラグメント化を最小にしておくのにいい仕事をするが、そのためにはファイルを連続した塊として配置できるようディスク上にはある程度の空きスペースが残されている事が必要である。それではどれだけの空きスペースを常時キープすべきか？決まった答えは無いが、ディスクの 20 から 25% というのが常識的な線であろう。
もし 60 GB ハードディスクで空きが 5 GB しかないとした時、それはその 5 GB 全部が一つの空きスペースとしてあると言う事ではない。普通、数十の、数百とは言わなくとも、小さなスペースの集まりである。最も大きな一つの塊の空きスペースの大きさはたったの 500 MB かも知れない。また、ディスクが本当に一杯の場合、空きスペースの絶対量が少ないだけではなく、使える最大の空きスペースのサイズもずっと小さくなってくる。これがフラグメント化が大きく進行する理由なのである。
それではフラグメント化しやすいファイルとはどんなものか？最もなりやすい候補は定常的に大きくなっていくファイルで、しかも一回に付け足されるデータ量があまり大きくないものである。毎回ファイルシステムはそのファイルを更新し、更なる空きスペースを探し、そしてファイルはその度にフラグメント化する。このプロファイルに合うファイルは色々あるが、何と言っても一番の候補はメールである。
私のメールプログラムの In box ファイルは 100 以上の部分にフラグメント化している。それは問題？いいえ、これは完璧に機能している。それでは私のメールプログラムを遅くしている？勿論、でも私が気が付くほどには。人々が自分のディスクを最適化するのは、自分の Mac をより速く走らせるためである。疑問の余地無く、Mac を使うのを多少速くするが、でも実世界で感じるほどの速度増加を見た事はほとんど無い。
そのプラスとマイナス面 -- Mac のスピードを、たとえそれが気が付かないくらいでも早くすることがハードディスクを最適化する一つの理由だ。ファイルをデフラグメント化するのには、実はもう一つの理由がある。もしディスククラッシュに見舞われたとき、当然突き止めなければならない断片が多くなるため、フラグメント化しているファイルのほうがしていないものよりもディスク復旧プログラムによる処理は難しくなる。そして、最もフラグメント化しやすいファイルは何だろうか? それは電子メールのファイルである。これは多分一番最後に変更されるものであろうし、そのためバックアップに含まれていない確率が一番高い。(ここでいつもの忠告。最近バックアップをしていないのなら、この記事を読んだあとすぐにバックアップを実行しよう。必ず。)
最適化をしない方が良い理由もいくつかあるが、皮肉なことにその理由の一つがスピードである。最適化ツールは遅いのだ。ディスクを最適化するのに何時間もかかる。メールを開くときほんの一秒早くするため Mac を何時間も拘束させておくことに意味があるのだろうか?
もっと心配なのは、最適化ツールが異常終了したときにディスクが“使用不可”の状態になってしまう可能性があることだ。これは、最適化ツールがディスク上のほとんどすべてのデータを移動する必要があるからだ。良くできた最適化ツールは、長時間に渡る最適化処理の途中で電源が切れてしまってもデータが失われないようなアルゴリズムを用いているが、それでもなおディスクのデータをプログラムが移動している限りは最悪の結果が起こる可能性はゼロではない。
つまり、完璧なプログラムはあり得ないということだ。初期の最適化ツールの中には、データを失ったりディスクを壊してしまうバグを持っていたものもあった。現在販売されている最適化ツールにこのような壊滅的なバグが含まれているという話は聞いていない。しかし、将来もそうであるとか現バージョンのツールを次期バージョンの Mac OS で動作させたときに問題が発生しないかということとは別問題だ。最適化ツールを使用する際には、充分注意すべきである。
最適化のアドバイス -- ディスクを最適化しようと思っているのなら、まず最初に Apple の Disk First Aid や Disk Utility などのプログラムでディスクを検査するのを忘れないで欲しい。ディスクが損傷していると、良くできた最適化ツールでさえ破損したデータや全く予期せぬ場所にあるデータによりクラッシュするかもしれない。
ディスク全体 (あるいは重要なデータだけでも) をバックアップするのも良い考えである。しかし、一度バックアップしてしまえば、あとはディスクを消去してバックアップを戻すという選択肢がある。これによりどんな最適化ツールにも負けないディスクの最適化が可能なのだ。さらに、ハードディスクを再フォーマットすることによりきれいなディレクトリ構造が得られ、もし再フォーマット時にゼロですべてのセクタを埋め尽くすオプションを選んでいれば (これは時間がかかるので不可解なディスクの問題に悩まされているのでなければ価値が無いが) 問題のあるブロックは使わないようにされることだろう。私のお気に入りの最適化ツールがRetrospect なのはこういう理由なのだ。これを使えばデータのバックアップと最適化を同時に行える。
<http://www.dantz.com/products/mac_express/>
Symantec 社製の Norton Utilities に含まれている Speed Disk には、ディスクを分析するのに便利な機能がいくつか備わっている。例えばディスク全般のフラグメント状況を軽度、中程度、あるいは重度と評価してくれるのだ。フラグメント状況が重度でなければディスクを最適化する価値はまず無いし、重度であったとしてもそのような場合が多々ある。それは、Speed Disk が重度にフラグメント化されていると判断する基準が、フラグメント化されているファイルの数、それらがどのようにフラグメント化されているか、そして Bツリー (ディスクのディレクトリ構造) がどのようにフラグメント化されているかを総合的にみているからだ。最後の項目が一番重要らしい。なぜなら、Bツリーが引き金となるからだ。もしこれがある程度フラグメント化していると、ディスク内のほかのファイルではそのような評価をされなくても Speed Disk はディスク全体が重度にフラグメント化していると判断してしまうことがある。
<http://www.symantec.com/nu/nu_mac/>
Speed Disk ではファイルと空き領域のグラフを見ることができ、どれだけ空き領域がフラグメント化されているかが一目瞭然だ。最大連続空き領域の値も表示でき、これは覚えておくと便利である。この値より大きなファイルは、セーブされるとき当然ながらフラグメント化するからだ。もしこの最大連続空き領域の値より大きなファイルを日常的に扱うなら、ディスクの最適化をすることをお勧めする。
最後になったが、Speed Disk はフラグメント化されているすべてのファイル、そしてファイルごとのフラグメントの個数をリストアップでき、個々のファイルをデフラグメント化できる。しかし、なぜそうする必要があるのだろうか? 理由はこうだ。HFS+ はファイルのカタログレコードで最大 8 個のフラグメントを扱える。もしファイルが 8 個以上のフラグメントを持っている場合、追加分のフラグメントを記録するため HFS+ は拡張レコードと呼ばれるレコードを追加する。8 個以上のフラグメントを持つファイルを開く場合毎回これらの追加レコードにアクセスする必要があるため、8 個以上のフラグメントを持つファイルはデフラグメント化する対象に充分なり得る。もちろん、デフラグメント化したことが実感出来るほどそのファイルにアクセスすることが前提になるが。
普通は個々のファイルに対してデフラグメント化するのに Speed Disk の機能を使う必要は無い。Finder でファイルの複製を作ることにより簡単に自分自身でファイルをデフラグメント化できるからだ。充分な連続した空き領域がありさえすれば、ファイルの複製時には一つのフラグメントしか使わないようになっている。複製を作ったあとは、オリジナルを削除し複製の名前をオリジナルの名称に戻して終わりだ。
Alsoft 社の DiskWarrior 3 は、ディスクのディレクトリで順番になっていない項目をカラーのグラデーションのグラフで表すユニークな機能を提供している。DiskWarrior の“再構築”機能は通常は損傷したディスクを修復するのに使われるが、正常なディスクに対して使うとディレクトリを“最適化”できる。Alsoft ではこの機能を“最適化”と呼んでいるが、これは他の最適化ツールとはまったく違うものだ。他のディスク最適化ツールがファイルのデフラグメント化を行うのに対し、DiskWarrior ではディスクのカタログを順序良く並べる。
<http://www.alsoft.com/DiskWarrior/>
カタログは、ファイルに対応するレコードを含むノードから成る。ノードはツリー構造を構成し、すべてのノードは特定の順番でお互いにリンクしている。ファイルシステムはこのノードを順序よく保とうとしている。しかし、ファイルがディスク上で追加あるいは削除される度にノードも作成され、消去され、そして順番が入れ替わり、最後にはバラバラになってしまうのだ。これは別に危険な状態でも、ましてや訂正すべき状況でもない。ただ単に最適でないだけだ。
DiskWarrior はこのノードの順序を並べ替える。理論上、これもデフラグメント化したファイルが速くなるのと同じ理由でディスクアクセスを速くするはずである。すなわち、関連した情報が一緒に格納されているので、情報を読むときにディスクのヘッドが離れたセクタ間を動かなくても良いということだ。現実には、ファイルシステムはカタログの重要な部分をメモリにキャッシュしていて、その情報がハードディスク上にしかない時と比べてアクセスが格段に速いので、顕著にスピードが速くなるとは私は思えない。Disk Warrior は損傷したディレクトリを持つディスクを修復する素晴らしいソフトだが、正常に動作しているカタログを最適化する場合目に見える効果は現れないだろう。
結論 -- 要約するなら、大部分の人にはほとんどの場合ディスクを最適化しても得られるものはさほど無いと言えるだろう。ディスクを最適化するのは間違ったことではないし、いつも使うファイルを読み込むときの反応が遅くなるような重度にフラグメント化したディスクに対しては実行したほうが良い場合もあるだろう。しかし、一般的には必要ではないし若干の危険もある。もしどうしてもディスクの最適化を行いたいのなら、一番良い方法はバックアップを取り (安全のためもう一つバックアップを取っておく)、ハードディスクを再フォーマットし、バックアップからから戻すことだ。
[David Shayer は Norton Utilities for Macintosh 3.0、4.0、そして 5.0の上級エンジニアだった。それ以前は MacUser Editor's Choice Award (審査員特別賞) を受けた Public Utilities と低レベルディスクエディタの Seditに携わっていた]
PayBITS: ディスクの最適化に時間やお金を浪費しなくて済むと知って良かったですか? そうであれば、PayBITS で David に感謝の意を送ってください。
<http://www.amazon.com/paypage/P12NE4WQ7K8ODD>
PayBITS の説明 <http://www.tidbits.com/tb-issues/lang/jp/paybits-jp.html>
文： TidBITS Staff <[email protected]>
訳： 亀岡孝仁 <takkameoka@earthlink.net>
Power Mac G5 の仕様 -- シリアル ATA バスの速度、ハードドライブの交換、熱放散、RAM 最大容量、そして更なるトピックがこの Power Mac G5 検証で論議されている。(27 コメント)
<http://db.tidbits.com/getbits.acgi?tlkthrd=1981>
旧型 Power Mac まだ入手可 -- Power Mac G5 の発表の後でも、Apple はいまだ Power Mac G4 モデルを売っている - それも Mac OS 9 への起動も出来る！(4 コメント)
<http://db.tidbits.com/getbits.acgi?tlkthrd=1982>
Mail の "Outlook" -- Apple の Mail アプリケーションは Mac OS X 10.3 Panther では HTML メッセージをレンダーするのに Safari エンジンを使う。それでは悪質なスパマーと戦うのに HTML レンダリングを制限するにはどんなコントロールが使えるか？(5 コメント)
<http://db.tidbits.com/getbits.acgi?tlkthrd=1983>
Motorola の PowerPC の将来 -- PowerPC G5 の発表で Motorola のPowerPC G4 プロセサには何が起きるのか？(2 コメント)
<http://db.tidbits.com/getbits.acgi?tlkthrd=1984>
G5 ベースの PowerBook -- 新しい PowerBook は PowerPC G5 チップをもうすぐ使うのであろうか... それとも？(6 コメント)
<http://db.tidbits.com/getbits.acgi?tlkthrd=1985>
Palm へのテキスト貼り付け -- Palm ハンドヘルドに簡単なテキスト切り抜きを貼り付ける簡単な方法は？読者がいくつかの方法を載せている。(4 コメント)
<http://db.tidbits.com/getbits.acgi?tlkthrd=1988>
非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
, 
日本語版最終更新：2005年 12月 26日 月曜日, S. HOSOKAWA