P前週号 | H日本語版ホーム | N次週号

TidBITS: Apple News for the Rest of Us  TidBITS#711/05-Jan-04

今年は Macintosh にとってどのような年になるだろうか? Adam は、Mac を改善するため Apple に何ができるかを予見し、また Web Crossing を使うことにより TidBITS を作成・管理する方法がもうすぐ変更される事について述べる。さらに Apple がクリスマス休暇前に出した Mac OS X、QuickTime、および iTunes のアップデートと共に、Tinderbox 2.1 のリリースをお知らせする。さらに、残念ながら Macintosh の指導者であった Phil Goldman 氏逝去の報に哀悼の意を表したい。今週私たちは Macworld Expo San Francisco に来ている。そこで皆さんと会えるのが楽しみだ!

記事:

Copyright 2005 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: <[email protected]>

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

MailBITS/05-Jan-04

Macworld Expo Hess イベントリスト -- 昨年の Macworld New York では中断したが、Ilene Hoffman 女史は再び今週の Macworld Expo in San Francisco に合わせて行われるパーティーや講演会、その他のイベントのガイドの決定版を作成した。この The Hess Memorial Macworld Events and Party Page には、報道やブース情報、そして一般に公開されているかどうかが記載されている。[JLC][佐藤]

<http://www.ilenesmachine.com/partylist.shtml>

Tinderbox 2.1 が HTML 書き出し、テキスト表示機能を拡張 -- Eastgate Systems 社は、同社のパーソナルコンテンツマネージャーである Tinderboxのマイナーアップデート版をリリースした ( TidBITS-651 の記事“Tinderboxでハートに火を点けて”を参照)。Tinderbox 2.1 では、自動でテキストを置換するためのマクロ機能、HTML 書き出しの柔軟性の改善、アンチエイリアステキストのサポートの向上、その他にも多くのものが新しくなっている。Tinderbox 2.1 は 1年間の無償アップデートが付いて 145 ドルであり、次の1 年間無償アップデート期間を延長するのは 70 ドルである。4.4 MB のダウンロードだ。[ACE][佐藤]

<http://www.eastgate.com/Tinderbox/>
<http://db.tidbits.com/getbits.acgi?tbart=06959>※日本語Tinderbox でハートに火を点けて
<http://db.tidbits.com/getbits.acgi?tbart=07292>※日本語Tinderbox 2 がウェブログツールを改善

DealBITS 抽選会: Insider Software 製品を射止めたのは? --grahams.net の David Graham 氏が第 4 回 DealBITS で見事当選し、Insider Software 社から FontAgent Pro 製品版が送られる。おめでとう。当選しなった人もがっかりしないでほしい。Insider Software は TidBITS の購読者全員に対し FontAgent Pro を 20パーセント引き、つまり 80 ドルで買える特典を用意している。この割引は 2004 年 1 月 12 日まで有効で、下記の 2 番目のリンクから辿れる。応募していただいた 525 人の皆さんにお礼を言いたい。そして次の DealBITS 抽選会もお見逃し無いように。[ACE] [佐藤]

<http://www.insidersoftware.com/>
<http://www.insidersoftware.com/dealbits1215.html>
<http://www.tidbits.com/dealbits/insider-software.html>
<http://db.tidbits.com/getbits.acgi?tbart=07477>※日本語DealBITS 抽選： Insider Software

Apple から数多くのソフトウェアアップデート

文： Adam C. Engst <[email protected]>
訳： 亀岡孝仁 <takkameoka@earthlink.net>

どうも年末に向けて狂気の様に頑張ったのは我々だけではなかったらしい。Apple のエンジニアの中には、各種のアップデートを一気に送り出してしまって年末祝日をよりゆったりした気持ちで楽しんだ人もいるようだ。年末に出されたアップデートには、Mac OS X 10.3.2, iTunes 4.2, QuickTime 6.5, そして Battery Update 1.1 が含まれている。

この中で最も重要なのは Mac OS X 10.3.2 で、色々な事が約束されている。Mac と PC の共存ネットワーク上でのファイルシェアリングとディレクトリサービスの改善、PostScript プリンタへの印刷の堅牢化、フォント管理の改善、Mail と Address Book へのアップデート、そして新しい ATI と Nvidiaグラフィックドライバである。Apple は Web に拡張した変更リストを載せている。あわせて、まだやっていない人のために 10.3.1 での改善項目と最近のセキュリティアップデートもバンドルされている。Panther でユーザーが経験した FireWire 400 ハードドライブとの間の問題については、残念ながらApple は一言も触れていず、単に 10.3.1 の時のノートである FireWire 800ドライブのユーザーはそのファームウェアをアップグレードすべきであるを繰り返しているだけである。Mac OS X 10.3.2 は Software Update 経由で 38.2 MB のダウンロードとして出されている；個別の 36.4 MB ダウンロードとしても入手可能である。

<http://docs.info.apple.com/article.html?artnum=25652>(日本語)Mac OS X: Mac OS X 10.3.2 Update について
<http://www.info.apple.com/kbnum/n120288>(日本語)Mac OS X 10.3.2 Update

iTunes 4.2 はかなりマイナーなリリースのように思える。主たる追加機能は AOL アカウントから iTunes Music Store への申し込みをサポートしたことである。また、iTunes 4.2 では iTunes Music Store を別個のウィンドウとして見ることが出来るし (ある曲をすでに持っていないかどうかを確かめるのに便利)、また数多くの性能改善が図られているという。iTunes 4.2 は 6.4 MB ダウンロードで Software Update 経由となっている；Mac OS X 10.1.5 かそれ以降が必要で、音楽をシェアするためには Mac OS X 10.2.4 かそれ以降が必要である。関連したニュースとして、Apple と AOL は、今や AOL の会員は AOL Music にある曲を、その曲の隣にある iTunes ボタンをクリックするだけで、試聴、購入、或いはダウンロードすることが出来ると発表した。これは、12月末時点で 2千5百万曲を超えた iTunes Music Store にとっては売上げを増やすのに役立ちこそすれ失うものは何もないいい話である。

<http://www.apple.com/itunes/>
<http://www.apple.com/pr/library/2003/dec/18aol.html>(日本語)Mac OS X 10.3.2 Update
<http://www.apple.com/pr/library/2003/dec/15itunes.html>(日本語)iTunes Music Storeからのダウンロード件数、2,500万曲を超える

QuickTime 6.5 は、Software Update 経由の 18.2 MB ダウンロード、3GPP2と AMC "mobile multimedia" フォーマットを作成したり演奏したり出来、テキストトラック対応と DV 再生オプションが改善され、そして iMovie, iDVD,更に Final Cut Pro 対応が強化された。QuickTime 6.5 は Mac OS X 10.2.5かそれ以降が必要である。

<http://www.apple.com/quicktime/>(日本語)QuickTime 6.5

最後に、白い iBook かアルミ製の PowerBook の持ち主は、Software Update経由で 520K のダウンロードとして Battery Update 1.1 を見ることになろう(160K の独立のインストーラとしても入手可)。Battery Update 1.1 では、バッテリーでも最大性能が引き出せるよう改善されたとされている。TidBITS Talk のユーザーからは Battery Update 1.1 と Mac OS X 10.3.2 をインストールした後では冷却ファンの動きが明らかに活発になったという報告も入っている；TidBITS Talk での論議を見られたし。もしこのアップデートをマニュアルでダウンロードしインストールしたならば、あなたのコンピュータにはこれが必要かどうか聞く警告を出してくる；Software Update に頼るのが最も簡単であろう。

<http://docs.info.apple.com/article.html?artnum=120281>(日本語)Battery Update 1.0
<http://db.tidbits.com/getbits.acgi?tlkthrd=2133>

追悼：Phil Goldman, 1964-2003

文： Jorg Brown <[email protected]>
訳： 亀岡孝仁 <takkameoka@earthlink.net>

悲しいお知らせがある。Apple でキャリアをスタートさせ Erich Ringewaldと共に System 6 MultiFinder を著作した Phil Goldman がクリスマスの翌日死去した。彼の名前が "About MultiFinder" ボックスに載っていたのを思い出せなくとも、彼が創始者の一人として始めた最も有名なベンチャーであるWebTV については聞いたことがあるのではないだろうか。更に最近では、challenge-response 法（人間にしか答えられないキーでメール送信の確認を求める）を使ったスパム排除のメールを提供する Mailblocks を立ち上げた。

通常の死亡記事であれば彼の職歴、妻と二人の子供、そして Brave Kids というチャリティとの活動（重病の子供達をインターネットを通じて家族との接触を保たせようとするもので、彼は WebTV を無償で提供していた）について書くところであろう。

しかし、私の記憶に残る彼は、ソフトウェアというものを最も深いレベルまで理解している非常に数少ないクラスの人々の一人としてである。彼は、ユーザーインターフェースを簡素化すること、ソフトウェアを誰にも使い易くすることから、ずっと進んで Mac OS はどうやってプロセススワップを効率的にこなしているのか...まで情熱的に語ることが出来、その上 MacsBug でデバッグまでやってのけた。彼はまた例外的なナイスガイでもあった；WebTV の時代、彼はよく San Francisco 49ers のチケットを余分に持っており、メールで知らせを出しそれが誰であれ彼のオフィスに一番最初に取りに来た人にあげていた。コンピュータ業界にいる我々の多くが個人的に彼を惜しむであろう。そして、彼の知性、洞察力、そして情熱を失った分、未来は貧しい。

<http://biz.yahoo.com/ao/031230/obit_goldman_1.html>
<http://nytimes.com/2003/12/31/technology/31GOLD.html>
<http://www.mercurynews.com/mld/mercurynews/business/7597357.htm>
<http://about.mailblocks.com/press_1228_2003_goldman.asp>

Web Crossing 開始

文： Adam C. Engst <[email protected]>
訳： 亀岡孝仁 <takkameoka@earthlink.net>

過去数週間の間、私は砂糖菓子を食べながら読んでいた "Visions of Sugar Plums" にはひまを出して、全く新しいサーバーソフトウェアの謎にどっぷり浸っている。数ヶ月前に私が TidBITS-700_ で "第 700 号、新しい CMS、そして Creative Commons" として書いた様に、我々はインターネットサービスの全てを、digital.forest がホストしているデュアルプロセッサ Xserve で走る業務用グレードの Web Crossing に乗り換える時間のかかる作業に入った。

<http://www.webcrossing.com/>
<http://db.tidbits.com/getbits.acgi?tbart=07385>(日本語)第 700 号、新しい CMS、そして Creative Commons

この様な大規模な乗り換えを、全てを走らせながらやるというのは大変である。それで私はまず内輪の大部分のメールユーザーと内部のメーリングリストのいくつかを Web Crossing に移すことから手をつけ始めた。これは、我々のずっと大きなメーリングリストを移すための準備でもある。翻訳配信リストとTidBITS Talk から始めて最後にメーンの TidBITS リストをやるつもりである。それを終えてから Web サービスの方に注力する。

今こんな話を皆さんにしているのには二つの理由がある。第一に、私が間違いをしてその結果メールがほんの短い間バウンスしたり、メールが重複したりといった混乱を招くかもしれないからである。この様な問題が起こっても、それが繰り返し起きない限り、私はすでにその問題に気づいていると思っておおごとにしないで欲しい。

第二に、そしてこちらの方がもっと重要なのだが、Web Crossing を導入する長所の一つが、皆さんが自分の購読登録を自己管理できる様になることである。当然、これをするためにはアカウントが必要になる。私がメールリストを古いリストソフトウェアから Web Crossing に移す度に、Mailing List Manager のアカウントが、あなたはこれこれのリストに登録されましたというメッセージを送ることになる。最初に受け取るメッセージには特に注意を払って欲しい。というのは、一番最後のところに、あなたの Web Crossing username (これは皆さんの email username と同じだが、時として重複を避けるためランダムな数字が付け加えられる場合もある)、ランダムに生成されたpassword、そして我々の Web Crossing サーバーへのリンクが表示されているからである。この情報を元に、Web Crossing にログインして、password を自分のものに変更する、購読登録を管理する、そしてメールアドレスの変更も出来る。もし password を忘れてしまったら、Web Crossing は新しいものを再度生成しメールであなたに送ることが出来る。

<http://emperor.tidbits.com/>

私はこの乗り換え作業をゆっくりやろうと思っている。一つには、Web Crossing の様に強力なソフトウェアを習得し構築して行くのは時間がかかるし (とりわけ日常の仕事をこなしながら)、それに私の進行にあわせて出していく変更依頼に Web Crossing の人達が取り組んでくれているからである。これまでの所、大変勉強になっている。どうか私がこの作業に取り組んでいる間、幸運を祈っていて欲しい。

Apple Computer、2004 年へと歩みを始める

文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

これまでは、年の始めの号ごとに私はその後数ヵ月の間に起こるであろうビッグニュースを予想して、程度の差こそあれ多少の成功を収めてきた。過去何年かの年頭の各号をどうぞご覧になって、私の記事に成績をつけて頂ければと思う。さて、今年はちょっと趣向を変えて、Apple がこれからどこへ向かって行く _べき_ なのか、ということを検討してみたい。

<http://db.tidbits.com/getbits.acgi?tbart=07035>(日本語)2002 年を振り返り、2003 年に期待する
<http://db.tidbits.com/getbits.acgi?tbart=06688>(日本語)2002 年の行く末を占う

これから述べることの基になったアイデアのいくつかは、私が 2003 年 10 月 の O'Reilly Mac OS X カンファレンスでのキーノートに端を発している。その講演の後、Tim O'Reilly と私は、Apple が首尾一貫していないという話題でひとしきり盛り上がった。Apple は、何らかのテクノロジーや機能を１つの製品では強調しつつ、他の製品ではそれを完全に無視したりする。Tim の言う通り、iTunes には真に素晴しい機能、例えば Rendezvous-ベースの共有音楽検出機能などが備わっているのだが、iPhoto が同じように Rendezvous-ベースの共有写真検出機能を持っていたら便利だとは思わないのだろうか？ 別の言葉で言えば、少なくとも外部の人間から見る限り、いわゆる「僕らが作ったんじゃない」症候群（つまり、自分たちが発明したテクノロジー以外は価値がないと考えてしまう傾向）が、個々の製品部門の単位にまで蔓延してしまっているように思えるのだ。

それでは、いくつかの分野に分けて、Apple がどんなことに努力を集中することが可能で、またそうすべきなのか、それによって同社の製品を向上させるとともに、“その他すべての我々”たる私たちに、より良い Macintosh 体験を提供してくれることもできるのではないか、という点を順々に述べてみよう。

予防的ハードウェアテスト -- Mac OS X は Macintosh の全般的な安定性を劇的に向上させた。ただ、私の経験では Panther は Jaguar よりもいくぶん気難しいようで、時折不可解なフリーズが私のデュアルプロセッサ 1 GHz Power Mac G4 で起こったりする。他の TidBITS スタッフたちの中にも、一部のサードパーティ RAM モジュールが Jaguar ではうまく動作していたのに Panther では始終クラッシュを引き起こす、というようなトラブルを経験した者がいる。

個々のトラブルは起こっては解決されていくのが当然で、全体の傾向が信頼性の向上に向けて進んでいる限り、私は声高に文句を言うつもりは無い。それよりも私が不安に思うのは、トラブルが起こる前にあらゆる種類のハードウェアの障害を特定して取り分けることができるような、充分なる診断・報告のメカニズムが、依然として私たちの手元には備わっていないことだ。例えば、何か問題が起こった時に、FireWire が悪いのかそれとも USB 機器が悪いのか、いったいどうやって見分ければよいのだろうか？ トライアル＆エラーで調べるしかないとしたら、昔と何も変わらないではないか。

Apple はこの点、正しい方向に進むための第一歩は踏み出しているようだ。Panther のディスクユーティリティでは、あなたのハードドライブの SMART の現在状況がレポートできるようになっている。この SMART (Self-Monitoring Analysis and Reporting Technology) というのは最近のハードディスクにたいてい装備されている機能で、ドライブの動作状況に関するさまざまの変数をモニターすることによって、少なくとも理論的には SMART がそのドライブが故障寸前になった時にあらかじめ予知することができるのだ。これは劇的な種類の故障を予知することはできない。だが、時を経るに従って小さな問題が積み重なった結果起こるような種類の故障を予知できるだけでも、それはそれで良いことであるには違いない。ディスクユーティリティを開き、左側のリストからドライブ（ボリュームではない）を選ぶと、ウィンドウの一番下のところに SMART ステータスが表示される。

<http://www.storagereview.com/guide2000/ref/hdd/perf/qual/featuresSMART.html>

それと同様に、Panther では Network 環境設定パネルで実際のネットワークステータスが表示されるようになった。例えばケーブルが外れたことや、あなたが自動割り振りの IP アドレスを持っているかどうかも表示され、どちらもトラブルシュートの際に大幅な時間の節約を可能にしてくれる。最後に、これも Apple が既に提供してくれている（少なくとも新型機種の Mac のいくつかで - すべての機種かどうかは不明）良い点だが、Apple Hardware Test Utility を使って Mac のハードウェアサブシステムの多くをテストすることができる。あなたの Mac に付いていたディスクを探してみるとよい。私の 12 インチ PowerBook G4 では、Apple Hardware Test は Software Install and Restore DVD の中にあり、マシンの起動時に Option を押し続けて、ブートディスクの代わりにこちらを選べば起動させることができる。

私の希望は、Apple がこうしたものをすべて一つにまとめ上げて、それらを自動的に走らせる方法を見つけ出して欲しい、ということだ。私が Apple Hardware Test utility のことを知ったのは Small Dog Electronics の技術サポートの人に走らせるように言われた時が初めてで、これは私の PowerBook で頻繁に起こったカーネルパニックやフリーズについて相談に行った時、その原因を探るための一方法として試してみるように言われたのだった。（結局、原因は RAM の不適合だったが。）さらに希望を言わせてもらえば、何かのプログラム、例えばファームウェアに埋め込まれたようなものでもよいが、それが起動時にハードウェアが変わっていないかを探知して、新たに加わった機器についてはテストを実行するかどうか自動的に尋ね、テストを実行することになれば自動的に、スケジュール実行される Unix のクリーンアップタスクなどと合わせて Mac がアイドル中の時間に実行してくれるようになれば嬉しい。

そのような機能は別にトップ広告を飾るようなものではないかもしれないが、Apple としても充分マーケティングの材料にはなると思うし、それよりも技術サポートのコストの低減や、顧客の満足度向上に役に立つと思う。このことを“予防的テスト”とでも名付けて新技術として売り出し、ユーザーの Mac に追加されたもの、例えば RAM とか、内蔵または外付けのハードドライブ、USB 機器などに対して、ある程度の基本的な検証が実行されることを保証するようにするのだ。コンピュータがいったん正しく動かなくなるととんでもなくやっかいなことになる、というのは誰でも知っていることだろう。トラブルが起こる前にハードウェアの故障を特定できたとしたら、これはもう Apple の大金星となること受け合いだ。

個人の人格を強調する -- Virginia 工科大学の Terascale Cluster に並んだ 1,100 台の Power Mac G5、というようなプロジェクトは別にして、Mac というものはこれまで常に単なる数の計算よりもコミュニケーションの方に重点を置いてきた。そのスタート当初の日から、Macintosh とは他の人とコミュニケーションをとるための道具であり、初期の MacWrite や MacPaint から、今日のインターネット時代における iChat AV、iTunes、iPhoto といった一連のアプリケーションに至るまで、Apple はそのそれぞれにより良いインターフェイスを組み込み、コミュニケーションのためのテクノロジーを Mac OS X に統合させ、iPod や iSight のような小さな機器にまで気を配って、消費者の気持ちを掴むことのできる仕事をしてきた。

<http://computing.vt.edu/research_computing/terascale/>

では、その次に来るべき仕事は何だろうか？ それは、個人の人格の尊重だ。あらゆる種類のコミュニケーションの基となるのが、個々の人格という概念だろう。けれども現在のところ、Apple のソフトウェアや各種のサービスはこの個人の人格については非常にあやふやな状態にある。あなた自身の身元を特定するために、あなたがしなければならないことを思い出してみよう。Mac にログインする時、ファイルサーバに接続する時、電子メールを送る時、いろいろなウェブサイト（Apple 自身の .Mac や Apple Store も含む）に接続する時、iChat を使う時や iTunes で音楽を共有する時、その他さまざまの箇所に、あなたの身元特定作業がばらばらに散らばって存在してしまっている。その上、これらの作業それぞれに違った方法で身元を特定しなければならない。でも、どこの場所でも、あなたという人は同じ一人の人格なのだ。

私のネットワーク内部のいくつもの Mac で私自身のアカウントにアクセスするために、いったいなぜ何度も繰り返して私の身元を証明しなければならないのだろうか？ いったいなぜ、別室にある私の Mac から私自身の共有音楽に iTunes でアクセスする際に、プレイリストを作ったり曲の操作をしたりするためのアクセス権が、赤の他人の権利と同じレベルしかないのだろうか？ いったいなぜ、全く別々のウェブサイトなら言うに及ばず、Apple 自身の運営しているいくつものウェブサイトでさえ、それぞれ別々のユーザー名とパスワードを、私が記憶していなければならないのだろうか？ ハードウェアやソフトウェア、それにウェブサービスまでも統合されているのが自慢のはずの Apple が、どうしてユーザーの身元特定に関しては統合しようとしないのだろうか？

身元の特定、そしてそれにかかわるアクセス権の概念は、将来のコミュニケーションにおける鍵となるだろう。私たちは、自分自身を他者に向けて特定するだけでなく自分にコミュニケーションを求めてくる他者をも特定する、その双方向の特定方法を必要としている。さらに重要なことには、個々のコミュニケーションの状況ごとに、それぞれの人がどこまでの事をすることが許されるのかを、明確に記述する方法が必要とされているのだ。Apple は、Mac ユーザーが電子的な単一の人格を作成して使用できるための機会を提供するために必要な構成要素は既に持ち合わせており、Apple はこの点での業界標準として油注がれることができるだけの機会を、他のどの会社よりも備えていると思う。（もしも Microsoft が信頼度という点においてもっと良い評判を勝ち得てさえいたら、そして .NET Passport をオープンスタンダードとして採用する決断を下していたら、きっともっと大きなインパクトを与えていたに違いないと思う。）

私は以前から、身元特定が大きな問題点になるに違いないと思っていた。だからこそ私は数年前にも、XNS (eXtensible Name Service) に多大の努力を注ぎ込んだのだった。残念ながら XNS は知的所有権の重荷に圧迫され、また XNSORG（私が座長となった非営利団体）と OneName Corporation（XNS を開発して XNSORG にライセンス供与した会社）との間にややこしい行き違いもあって、困難に面してしまった。もう一つ大きかったのは OneName 社が資金源を見つけられなかったことで、会社として生き残ることには成功したものの首の皮一枚という状態で、現在 Chapter 11 の下で破産管財処理による再建の途上にある。XNSORG はと言えば、やはりずっとかろうじて歩み始めの段階を脱せずにいる。

<http://db.tidbits.com/getbits.acgi?tbart=06133>(日本語)XNS と XNSORG がデビュー
<http://db.tidbits.com/getbits.acgi?tbart=06485>
<http://www.onename.com/>
<http://www.xns.org/>

これらの困難にもかかわらず、そしてそれはほとんど Drummond Reed 一人の個人的奮闘のおかげなのだが、XNS はまだ生きている。そして、その技術的仕様書は現在 OASIS、グローバルな非営利標準の協会団体による保護の下にある。XNS の Extensible Resource Identifier 仕様は先月 OASIS の XRI Technical Committee から承認を受けたばかりだし、XDI (XRI Data Interchange) 仕様に関する第二の OASIS 技術委員会のための憲章も、やはり先月申請されたばかりだ。幸運に恵まれれば、これらの技術仕様が OASIS に認められて、他の団体、例えば Apple にも、これらのオープンスタンダードに基づいた身元確認サービスを開発する気運が生まれてくるかもしれない。

<http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri>
<http://www.onename.com/standards.html>

オープン対専有のバランスビーム -- Mac OS X は、オープンソースの世界の良いところと専有ソースの世界の良いところとを混ぜ合わせようという、壮大な実験であった。伝説的とも言うべき Apple の使いやすさを、同じく伝説的なオープンソースの Unix 具現におけるパワーの上に構築したのだ。ハイレベルのものにおいてさえ、Apple は開発者たちが手軽に素早くアプリケーションを作れるためにオープンな枠組みをうまく作り出すことに成功している。そのいくつかは比較的有名なもので、例えば WebKit のフレームワークはアプリケーションにウェブへのアクセスを組み込むのを大幅に簡略化した。他の例はそれほどよく知られていないが、例えば Apple のシステムワイドなコンタクトデータベース、Address Book などがある。

ユーザーにとっては、Address Book はコンタクト情報を追跡するための比較的単純なアプリケーションにしか見えないかもしれない。けれども実際は、これは Address Book フレームワークの単なるフロントエンドに過ぎない。そしてその事自体、MetaKit と呼ばれるオープンソースのデータベースとの間で情報を交換するための一つの方法に過ぎないのだ。その結果として、どんなアプリケーションでも Address Book データベースとの間で双方向の読み書きができ、どのフィールドを扱うのかを選んで指定したり、カスタムフィールドを作成したり、さらには個々のフィールドに特定のアプリケーションから来たものとマークを付けることさえできる。現在では、既に多数のアプリケーションがこれらの能力を利用しており、その数はますます増えつつある。

<http://www.equi4.com/metakit.html>

このようなフレームワークを作り出すことには、少なくとも２つの非常に大きな利点がある。１つには開発者たちにパワーが与えられること、例えば Safari に対抗したアプリケーションを作るのは困難に見えるかもしれないが、WebKit フレームワークのお陰でその困難さがかなり低減されている。（実際、今度の Macworld Expo でプレリリース版がお目見えする予定の OmniWeb 5 は、WebKit を利用して Safari のレンダリング能力に対抗しつつ、同時に Omni Development 社がこれまで培って来た、ウェブブラウザのインターフェイスが如何にあるべきかという知見を盛り込んだものになっている。）けれどもそれよりももっと興味深い利点がある。それは、あなたのデータが特定のソフトウェアの捕虜になってしまう心配がないことだ。例えば、もしもあなたが Address Book における Apple のインターフェイスが気に入らなければ、少なくとも理論的には他の開発者の作ったフロントエンドに乗り換えることが可能なわけだ。

<http://www.omnigroup.com/applications/omniweb/5/>

だが、ここで Apple の首尾不一貫が目に付く。もしも iPhoto が、現在のように完全に Apple 専有のものでなく、何か汎用の画像カタログ用フレームワークの Apple 自身による一つのフロントエンドに過ぎないものだったとしたら、ユーザーたちの心配ごとは劇的に減少することだろう。自分の写真をすべて iPhoto にお任せしてしまうことは言うに及ばず、それらの写真に付随してそれに意味を与えているすべてのメタデータ（タイトル、キーワード、アルバムなど）も、皆 iPhoto の中に取り込まれてしまっているのだから。その上、もしも開発者たちの手によって iPhoto の機能の一部が拡張、さらにはより良いものに置き換えられたりできるようになったなら、iPhoto を使う気になれないという人たちも含めて、大きな可能性が開けてくることだろう。

私がここで言いたいのは、Apple 社内の一部ではオープンフレームワークの上にテクノロジーを築き上げることの利点が理解されているにもかかわらず、その信念が会社内の隅々にまでまだ行き渡っていないのが明白だ、ということだ。iPhoto のような、専有のテクノロジーを使ったクローズドなやり方は、確かに消費者たちにとっての Mac の魅力を増すために有効かもしれないが、他方では他の開発者たちが Mac を消費者たちにとってより一層魅力的なものに押し上げることのできる機会を奪っている。

よこせ、もっとスピードを！ -- コンピュータのパフォーマンスというのは実は非常に微妙な話題だ。速度の向上はハードウェアの改善に依存し易いし、そのことによってマシンの老朽化が印象付けられ、そのお陰で Mac ユーザーたちが何年かに一度は新しいマシンに買い換える動機付けが生まれるのだから。もしも古い Mac が最新のソフトウェアを走らせても遅く見えなかったとしたら、多くの人たちが今よりももっと長い間古い Mac を使い続けることになり、ひいては Apple 社の基盤に悪影響を与えかねないのだから。

Mac OS X のパフォーマンスは、10.0 の段階ではほとんど使い物にならない代物だった。はっきりと使える感じがし始めたのが 10.1 で、それから 10.2 に至って完璧に順当な使い心地のレベルに達した。そして、どうやら Apple はこの「完璧に順当な」レベルで充分、と判断してしまったようだ。いくつかのマシンでは、Panther は Jaguar よりもやや速く感じられるが、私のデュアルプロセッサ 1 GHz Power Mac G4 では、これまで Jaguar で経験したのとは比べ物にならないほどの頻繁さで Panther が例の「死の回転ピザ」を見せてくれるし、全般的に言って、私の Mac は以前より反応が鈍い感じになった。どちらにしても、私の不満は解消されていない。Mac OS X は依然としてまだ一度も Mac OS 9 のあのキビキビした感じを取り戻していないし、今日のコンピュータに装備されているハードウェアの性能を考えれば、もっと強烈なスピードを感じさせてくれてもいいと思うのだが。

というわけで、私は Mac OS X がもっと高速化されるのを心待ちにはしているが、一方ではそれは実現されないのではないか、というあきらめに近い境地にいる。なぜなら、Apple がそれを実現するために必要な人的投資をおこなう気があるとは思えないからだ。とりわけ、現状を維持さえしていればハードウェアアップグレードによる現金収入が入り続けるのだから。

そのことはさておき、パフォーマンスに関連する他の３つの分野で、Apple がユーザーの Macintosh 体験を改善させられるし、またそうすべきだと思われるものがある。これらはいずれも、計算力のパフォーマンスではなくて機能上のパフォーマンスに関するものだ。計算力のパフォーマンスは、単にプロセッサのスピードを上げたりコードの能率化を図ったりして、実行時間を短縮すれば済むものだ。けれどももっと重要なのは機能上のパフォーマンスで、これは言い替えれば使い易さを向上させてユーザーが仕事を完了するまでにかかる時間を短縮するのだ。皮肉なことに、往々にして機能的パフォーマンスを上げようとすれば計算力パフォーマンスを犠牲にせざるを得ないことがある。なぜなら、ユーザーの操作を単純化するためにはプログラムがその分 CPU サイクルを消費することになるからだ。今日、こんなにもグラフィカルなインターフェイスに人気があることも、機能的パフォーマンスのために CPU サイクルを振り向けることの重要性の証拠となるだろう。

第１に、Mac OS X のあの恐ろしい「死の回転ピザ」は、現在アプリケーションが応答できないことを示している。その原因はアプリケーションがクラッシュしたのかもしれない。その場合には回復の見込みは無い。または、アプリケーションがただ長時間かかる作業を実行中なだけかもしれない。Mac OS 9 においては、たいていの場合このような長時間の作業を Command-ピリオドを押して中断させることができた。私は、この機能を Mac OS X に復活させて欲しいと思う。ちょっとした間違いのためにアプリケーションが数分間もどこかへ行ってしまい、その作業を中断させる方法も無くてただ待っているだけ、というのはとにかくフラストレーションが溜まるものだ。特に、ネットワークボリュームがアクセスできないことを Finder が認識するまでのあの長い待ち時間は耐え難いと思う。

第２に、皆さんは昔々のユーティリティ、Hiro Yamamoto の Boomerang を覚えておられるだろうか？ このユーティリティがあれば、最近開いたことのあるファイルやフォルダを開くのが簡単になった。Boomerang 自体はその後（Super Boomerang として）拡張され、また別の形に複製されたりして生き続けたが、これの本質を成す考え方を引き継いだ開発者たちの数はそれほど多くはなかった。Boomerang は、あなたの最近の過去の動作が、あなたが近い将来繰り返す可能性の高い動作でもあることを理解していたのだ。この考え方を一般化すれば、「現存のデータを、近未来の動作を簡素化する（従って高速化する）ために利用できる」ということだ。これは非常に微妙ながら非常に価値のある教訓であり、現に Apple のソフトウェアの中にもこれを取り入れているものがいくつかある。例えば、Address Book はそのフィールドの多くで、現存のコンタクト情報のデータをもとに入力データを完備化することができる。Displays メニューは、あなたが最近選択した解像度のみを表示する。Command-Tab を素早く叩くと、動作中の全アプリケーションをリストする代わりに最近使った２つのアプリケーションの間だけを行き来する。けれども、それ以外のあまりにも多くのアプリケーションが、Boomerang の教訓を全く理解しようとしないか、または取り入れても中途半端なままだ。例えば Safari は URL の自動完備化をあなたが最近訪れたページに基づいてしてくれるが、それはあなたが URL を頭からタイプし始めるか、または www の後のドメイン名をタイプした場合のみだ。また、iPhoto には現在のところ、新たに読み込んだ写真について過去に読み込んだ写真やあなたの過去の操作などと比較することによって整理や分類を手助けするような機能は全く無い。Apple 社内であろうと独立のアプリケーションの仕事であろうと、どんな製品の開発チームも皆、ぜひともよく考えて、ユーザーの過去のデータや過去の操作に基づいてユーザーのためにより良い仕事をしてくれるソフトウェアを作る道を探って行って欲しい。

第３には、システムの各部分の編成方法に関する不満がある。これは、事あるごとに Tim O'Reilly が問題提起してきた点だ。Apple 社内の誰かが、この際ぜひとも Apple 製品のうちどの製品のどの部分が最もユーザーの作業を効率化するために高度に機能的なインターフェイスを成しているかを _分析_ して、その上でその部分のアイデアを他の製品群にも拡げて行くための仕事をする必要がある、というのだ。例えば、iTunes は Top 25 Most Played プレイリストを使ってどの曲をあなたが最も頻繁に聴いているかを追跡できる。このアイデアを iChat や Mail でも提供して、あなたが最も頻繁にチャットしたりメールしたりする相手を示すことができたら便利ではないだろうか。（この例は実際のところ Boomerang の教訓を直接取り入れている。つまり、最近通信した相手はあなたが次回にまた通信する相手である可能性が高い、ということだ。）このようなアイデアの拡大を、どのようにして実現したらよいだろうか？ Tim の提案はこうだ。これは Apple 外の開発者たちのためにもなる点で良い考えだと思うが、何か組織的な書類、例えば元々の Apple Human Interface Guidelines に似たものを作って、現存のアプリケーションで最高の手腕を発揮しているものを分析し、それを元に、相互に関連のあるアプリケーションがどのように振る舞うべきかを述べるようにしてはどうか、という考えだ。

ファイル共有、その次世代は -- Macintosh は、パーソナルなファイル共有を導入することで新地平を切り開いた。これは、どんな Mac でもファイルサーバとして振る舞うことを可能にしたからだ。それ以来、私たちはどれほど長い道のりを歩んできたことだろうか。Mac OS X の Sharing 環境設定画面にリストされた様々のファイル共有プロトコルの種類を眺めただけでもそれはよくわかる。また、Rendezvous の導入によって、私たちが一旦は AppleTalk から TCP/IP への移行によって失っていた機器を発見する手軽さが主たるネットワークプロトコルとして私たちのもとに戻ってきた。

このようにファイルを共有する多数の新しい方法や、Rendezvous のような改善は実現されたものの、Apple はファイル共有で最も重要な点の開発については過去十年間何もしないできた。それが、ピア・ツー・ピアのファイル共有だ。今に至っても私たちは機器中心のファイル共有の枠を出ることができず、そのため共有ファイルで仕事をしようと思えば、どのサーバがそのファイルを保持しているかを覚えていなければならないし、ユーザ名とパスワードを入力して、そのサーバに明示的に接続しなければならない。そしてそのことすべてが、その特定のサーバにネットワーク接続が可能だということを大前提にしているのだ。

ファイル共有は、そこまで限定されたものでなければならないのだろうか。現実に、DataClub という名前の製品が 1990 年代の初頭から別の方法を提示していた。DataClub を使えば、ネットワーク上のすべての Mac がそれぞれに一定の領域を“cloud”なるものに提供し、その could が共有ファイルを保持した。この could の中のすべてのファイルは、それが実際にどの Mac に存在していようとも、あたかも１つのボリュームの中にあるように見え、そしてもしもあるファイルを保持している Mac の電源が切られれば、そのファイルはグレー表示されて利用できないことが示された。

<http://db.tidbits.com/getbits.acgi?tbart=03212>

この DataClub の時代以降、私たちはピア・ツー・ピアのファイル共有ネットワークの隆盛を目撃してきた。Napster、Kazaa、eDonkey2000 など、多数のものが登場した。けれどもこれらのテクノロジーはどれも、Mac OS には登場しなかった。たぶんその理由は、無知な人々が訳も分からずにこれらを音楽その他著作権物コンテンツの交換行為と混同してしまうことを恐れたのだろう。

私は、Apple がピア・ツー・ピアのファイル共有テクノロジーを Mac OS X に組み込んで、Mac のネットワークと Macintosh ユーザーたちが、単なる個別の機器というレベルを超えて、もっとパワフルかつ柔軟性を持った働きができるようにして欲しいと思う。共有された同じファイルの複数個のコピーがいくつかのマシンに保存されていれば、どれかの Mac の電源が切られた場合や PowerBook を持って旅行する場合の問題も防げる。いくつものサーバを探し回る作業はもはや過去のものとなる。共有されたファイルは、あたかもいくつかのローカルなフォルダの中にあるように、いつでもただ利用可能なものになるだろう。そのようなシステムでは、自動的にバックアップをとってそのバックアップデータは非共有のものとして保存し、それを暗号化されたいくつかの部分に切り分けてネットワーク上の複数個の Mac に分散して置いておく、といったことも可能になるだろう。このようなことはすべて高速のローカルネットワークにおいて最も実現可能だろうが、適切にデザインされ正しく具現化されさえすれば、これをインターネットにまで拡張していけない理由は何もない。

ファイルシステムのデータベース -- Apple と Mac OS X の将来の進むべき方向を検討したこの記事の締めくくりとして、さきほど述べた共有ファイルの cloud がもう少し下方の技術的レベルにおいてどのようなことを要求することになるのかについて少し触れてみよう。共有すべきファイルを、あなたはどのようにマークするのだろうか。そのファイルに誰がアクセスできるのかを、どのように決めるべきだろうか。そしてその具体的方法は？ 一方、この等式の他辺に目をやれば、他のユーザーはどのようにしてあなたが共有したファイルを見つけるのだろうか。そのユーザーがそのファイルを編集しようとした時に、もしも別の誰かが既にそのファイルを開いていたとしたら、何が起こるのだろうか。

これらの疑問の答えはすべて、ファイルというものをデータベースのオブジェクトとして扱うことによって手にすることができる。なぜなら、データベースのテクノロジーこそが、パーミッション、ユーザーとグループ、メタデータ、記録のロック、といった形で遥か昔からこのような問題を取り扱ってきたからだ。けれども現在ディスク上のファイルを管理しているファイルシステムは、データベースとしては甚だ貧弱なもので、さきほど述べたようなピア・ツー・ピアのファイル共有システムを効果的に動作させようと思えば、ファイルシステムの基盤にもっと堅牢な、ハイ・パフォーマンスのデータベースを据えることがどうしても必要になるかもしれない。この考え方は必ずしも新しいものではない。私自身 1992 年の TidBITS エイプリルフール特別号で既にこの概念に触れているし、1996 年の２つの記事ではシステムレベルのデータベースの有用さについてさらに詳しく述べている。

<http://db.tidbits.com/getbits.acgi?tbart=03159>
<http://db.tidbits.com/getbits.acgi?tbart=00906>(日本語)データベースの再来
<http://db.tidbits.com/getbits.acgi?tbart=00900>(日本語)システムレベル・データベースへのコメント

ファイルシステムの基盤にデータベースがあれば、Finder におけるフォルダはもっと汎用の意味を持つコンテナとなることができ、その内容も常にアップデートされる検索に基づいたものにできるため、例えば一人のユーザーが共有に使っているファイル全体とか、または特定のグループに利用を許可されているファイル全体とか、そういう集まりであることもできるだろう。その上でさらに追加のメタデータが加われば、利用可能なファイルのリストにさらに条件を入れて、例えば特定のプログラムで作成されたもののみに制限したり、特定の日付の範囲内のもののみに制限したり、といったことも可能だろう。記録のロックができれば、二人の人が同じファイルを同時に使おうとした時に片方のユーザーの変更を他方のユーザーが上書きしてしまうのが防げるだろう。状況によっては、ファイル全体でなくもっと細分した単位についてロックが実行できるかもしれず、そうすれば複数の人がお互いの変更に踏み込むことなく同時に一つのファイルを編集できるようになるかもしれない。これは現在既に SubEthaEdit でリアルタイムの共同テキスト編集作業が実現されているのと同じ考え方だ。

<http://www.codingmonkeys.de/subethaedit/>

データベースをファイルシステムの基盤に据えるという考え方は、新しくないというだけでなく、現に Microsoft の WinFS として実現されることになっており、これは数年以内に出る予定の Windows の次期メジャー改訂版に組み込まれるという。

<http://msdn.microsoft.com/Longhorn/understanding/pillars/WinFS/default.aspx>

さて、次のステップは？ -- 以上述べてきたような提案がたやすく実現できるものでないことは充分承知している。けれども、少なくとも Apple 社内の一部のグループでは、これらのことの重要性が認識されている。だから、私は述べたことがただ無為に消え行くだけにはならないことに期待をかけたい。問題は、Apple の経営陣がこれらの一般的な概念の中から最も力強いものを選び取り、それをより多くの製品へと拡げて行くことで、現在はまだ特定の分野のみでしか最高の仕事が発揮されていないものを、今後は全体的な Mac 体験をより良くするものへと昇華させて行けるかどうかにかかっている。

TidBITS Talk/05-Jan-04 のホットな話題

文： TidBITS Staff <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

最近のアップデート後における PowerBook 内蔵ファンの動作 -- Apple の Battery Update 1.1、あるいはおそらくそれと Mac OS X 10.3.2 との組み合わせが、いくつかの PowerBook や iBook において内蔵ファンの活動を増大させているようだ。これは欠陥なのか、それともこのやたらに熱いアルミニウム製 PowerBook を充分に冷却するための必要事項なのだろうか？ (メッセージ数 11)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2133>

tb_badge_trans-jp2

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

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

P前週号 | H日本語版ホーム | N次週号