TidBITS#714/26-Jan-04 TidBITS#714/26-Jan-04今週は Macintosh 誕生の 20 周年を記念して、Adam が Bruce Horn と対談する。Bruce は Finder を書いた人物だ。彼が Apple でどんな仕事をしたか、退社後は何をしてきたか、彼が現在どんな Macintosh プロジェクトに取り組んでいるかが語られる。また、Brady Johnson から再びの寄稿記事では、合衆国の新しい連邦 CAN-SPAM 法がますます増え続けるスパムメールの量を抑える効果を持つのかどうかが検討される。ニュースの部では、Dantz が Retrospect 6 をリリースし、OrangeWare からは Atheros 製のチップセットを使ったワイヤレスカード用の Mac OS X ドライバが出て、そのカードには、802.11a が使えるものがある。
記事:
Copyright 2005 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: <[email protected]>
本号の TidBITS のスポンサーは：
TidBITS のスポンサーになって仲間をふやし知名度を上げませんか！日本からも素晴らしい製品を、数万人に及ぶ経験豊かで熱心な全世界の Macintosh ユーザー に見てもらいましょう。実際にものを買うのはこの人たちなのです！詳しい情報や料金については <[email protected]>. へメールを。
読者のみなさん! あなたのカンパで TidBITS を応援してみませんか？ 
今週は、 Peter Morgan 氏、 ApplesBC Computer Societyの暖かい支援に感謝!
<http://www.tidbits.com/about/support/contributors.html>
SMALL DOG ELECTRONICS: iBooks On Sale!
iBook 12-inch G3/800, Only $739! iBook G3/800 640 MB RAM, $739!
iBook G3/900 14-inch 640/60/Combo/56K/AirPort, Only $1,149!
Visit: <http://www.smalldog.com/tb/> 802-496-7171
FETCH SOFTWORKS: Is maintaining your Web site tedious? Use
Fetch, the original Macintosh FTP client, and you can record
AppleScripts that automate repetitive uploads and downloads.
Get Fetch now at <http://fetchsoftworks.com/>!
Discover, Master, and Unleash the Music in You!
The Big Mix from Aladdin Systems delivers nine awesome titles
in one complete audio package. Get the Big Mix for only $69.99.
<http://www.aladdinsys.com/store/tidbits/bigmix.html>
DR. BOTT, LLC: Explore our vast assortment of iPod accessories!
NaviPod wireless remote; PocketDock for using standard FireWire
cables with your 3G iPod, and other startlingly cool gear for
enhancing your digital lifestyle. Visit <http://www.drbott.com>
Web Crossing: now with plug-ins for blogs, wikis, RSS, and more.
Web Crossing v5.0 now sports a new plug-in architecture and
easy customization, yet it's still fast and powerful. Try our
free Web & email server! <http://www.webcrossing.com/tb-104>
Mac ユーザーも“A”リストに加わる -- Apple の AirPort Extreme (IEEE 802.11g)（注： 日本では AirMac Extreme）ワイヤレス・ネットワーキング・システムが 2003 年 1 月に発表された時、Steve Jobs は同程度に高速だけれども古いシステム 802.11a は死んだ、と宣言した。彼の説明では、802.11a は AirPort (802.11b) や AirPort Extreme の標準とは異なる周波数帯を使用しており、そのため過去のものとして封印しなければならない、ということだった。後方互換性が欠けている以上仕方がない、というのが理由だった。けれどもそれから１年が経って、802.11a は新たな立脚点を得ることになった。その周波数帯に、追加の周波数が割り当てられたのだ。それ以降、多数のワイヤレスカードが Apple 以外のメーカーから出されて、802.11a、b、g のいずれをも扱えるようになってきた。802.11b や 802.11g では心配となるラジオ電波からの混信が 802.11a では問題ない、というのがその大きな動機だった。ただ、Mac ユーザーはこれまでこの技術革新から取り残されていた。
けれども今回、OrangeWare から 3Com 用に開発されたソフトウェアドライバが売り出され、Atheros 製の一連のチップをサポートするようになった。Atheros は、Apple のワイヤレス製品に使われている Broadcom のライバル社だ。この OrangeWare のドライバを使えば、Atheros ベースのワイヤレスカードを Mac OS X で使えるようになる。ただ、Mac ユーザーたちは AirPort 3.1 ソフトウェアアップデートがリリースされて以来、AirPort Extreme 製品ラインアップで使われている Broadcom のチップを持つ Linksys、Buffalo、Belkin その他の 802.11g カードを使ってきた。$15 で使える試用版の OrangeWare ドライバでは、NetGear、Fujitsu、D-Link その他のメーカーの 802.11a あるいは a/g 兼用の PC ないし PCI カードが使える。OrangeWare では、テスト済みのカードの短い一覧表を発表している。[GF]（永田）
<http://www.orangeware.com/endusers/wirelessformac.htm>
DealBITS 抽選： Cocoatech 当選者 -- おめでとうございます。先週の DealBITS 抽選に当選したのは yahoo.com の Gloria Harman と pobox.com の Richard I. Levine の二人で、それぞれ Cocoatech の Path Finder を賞品として受け取っていただく。残念ながら当選しなかった皆さんもがっかりすることはない。Cocoatech では、TidBITS 読者の皆さん全員を対象に、Path Finder を平常価格の $34 から $29.95 の特別価格に値下げして提供している。この特別価格は 2004 年 2 月 02 日（米国時間）まで有効で、下記の２つ目のリンクを使えば割り引きが受けられる。応募して下さった 564 名の皆さんに感謝すると共に、今後の DealBITS 抽選にもご期待頂きたく思う。[ACE]（永田）
<http://www.cocoatech.com/>
<http://www.cocoatech.com/tidbits0104/>
<http://www.tidbits.com/dealbits/cocoatech.html>
<http://db.tidbits.com/getbits.acgi?tbart=07508>(日本語)DealBITS 抽選： Cocoatech
文： Glenn Fleishman <[email protected]>
訳： 亀岡孝仁 <takkameoka@earthlink.net>
Dantz Development の伝統ある Retrospect バックアップソフトウェアが、今日出荷となったダウンロード版のリリースで Panther のフルコンパチとなった。Retrospect 5.1 でも Panther 下で動くが、そして Retrospect Client も Panther 下では問題なく動くが、Dantz は避けるべき状況のリストと、再起動やシステム障害のあとアプリケーションを起動し走らせる時に発生する問題とを発表していた。(我々のバックアップサーバは当分 Jaguar のままで行く。)
<http://www.dantz.com/>
<http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=28093>(日本語)http://www.dantz.com/jp/
Retrospect 6.0 は、次の四つの特別な場合の一つに当てはまらなければ、強烈に高い値札の付いたメンテナンスアップグレードと見ることが出来る：1 テラバイトより大きなバックアップセットを作る；Xserve RAID にバックアップする；SCSI か Fibre Channel を通してテープライブラリを使う；或いは Adam が彼の現在のハードドライブベースのバックアップストラテジーで経験したような、複数のハードドライブを一つのバックアップセットでまかなう。同社では、速度も向上していると言っている。
<http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=28121>
<http://db.tidbits.com/getbits.acgi?tbart=07295>(日本語)FireVue でバックアップ
このソフトウェアは現在ダウンロードで入手できる；箱入りの方は二月の中旬になると言う。値段は複雑である。いつもの様に、小、中、大のネットワークのために Dantz が設定している版の数だけある。
Retrospect Desktop は、一台の Mac（自分自身）とネットワーク上の Windows, Mac OS, 或いは Red Hat Linux システムの二台を同梱されている Retrospect Client を使うことでバックアップできる。しかしながら、Mac OS X Server を走らせているコンピュータ（直付けでも Retrospect Client を使ってでも）はバックアップ出来ない。それに、大きなテープセット、Xserve RAID、或いはテラバイトオプションは提供していない。リスト価格は $130 で以前のバージョンからのアップグレードは $60 である。
Retrospect Workgroup と Retrospect Server はそれぞれクライアントとして 20台と 100台とをサポートし、大きなデータのオプション全てを含む。しかしながら、Mac OS X Server システムをバックアップできるのは Retrospect Server だけである。Workgroup のリストは $500 でアップグレードは $200；Server は $800 とアップグレード $350 である。
もし Mac OS 9 システム上で Retrospect を走らせたければ、全てのバージョンには Retrospect 5.1 が含まれている；Retrospect 6.0 で Retrospect Client ソフトウェアが走っていれば旧型 Mac でもバックアップ出来る。更にブータブルなデザスタリカバリ CD も含まれるが、これは箱入り版だけであり、電子版のみの購入では対象とならない。
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Macintosh が生まれて 20 年が経った。今年の Macworld Expo で、Steve Jobs は Mac 誕生時のあの有名なテレビ広告“1984”を一捻りしたものを上映したし、AppleTalk の大部分の責任者であった Alan Oppenheimer も、Mac でネットワークすることの歴史について素晴しい講演をしてくれた。けれども私が一番おもしろいと思ったのは、20 年もの月日が経ったにも拘わらず、当時から元々居た人たちが今でも健在であるだけでなく、今でも最高度の作品を作り続けてくれているということだった。Macintosh の歴史は、現在も書き換えられつつあるばかりではなく、当時と同じ人たちが、今でもその書き換えの仕事を続けてくれているのだ。
<http://www.opendoor.com/nethistory/>
さて、ここで皆さんに Bruce Horn をご紹介しよう。彼もまた、当初の Macintosh 開発チームの一員であったのだが、彼は Mac の核心を成す鍵となった数々の事柄を産み出した人でもあり、その後も革新的なコードを書き続けてきた人だ。Apple に在籍していた頃は、Bruce は Finder (おお、あの Finder か！)、ファイルやアプリケーションに対するタイプ・クリエータのメタデータのメカニズム、それにリソースマネージャ (ファイルのリソースフォークの読み書きの管理をする - その後 Apple の技術仕様書にはっきりと宣言されていた文句を思い出そう：「リソースマネージャはデータベースではない！」)、といったもののデザインと実装の責任者だった。また、ダイアログマネージャや、複数種類のタイプの内容を扱えるクリップボードなどといったものも、Bruce の発想力のお陰によるところが大きいらしい。
そこで、Macintosh の誕生 20 周年を記念して、私は Bruce と対談して、彼が Apple でした仕事だけではなく、彼が現在取り組んでいる仕事についても語ってもらいたいと思った。なぜなら、多くの点で彼の現在の仕事は、彼の出発点にたち帰るものでもあり、一方では未来の Macintosh に何が可能なのかということを、かいま見せてくれるものでもあるからだ。
Adam： Bruce、開発当初の Mac について君が仕事をしたいろいろな点の多くは、構造を持ったデータにアクセスする方法についてのものだったのじゃないかな？ Finder はファイルシステムのフロントエンドだったし、リソースマネージャというのは、あの仕様書の宣言とは反対に、まさにフラットファイルのデータベースそのものだったと思う。それからタイプ・クリエータコードのメタデータにしても、見れば見るほどデータベースとして使ってくれと叫んでいるようなものだ。こういうのは、君が初めから計画したものだったのか？ それとも、作業をしながら自然にその方向に向かって行ったのだろうか？
Bruce： 元々はいくつかの違った目標があって、それが結局こういう結果にたどり着くことになったんだ。それ以前の僕のプログラミングの経験と言えばほとんどが Xerox の Smalltalk 環境でのもので、そこではすべてがランタイム中に好きなように変えられた（つまり、プログラムが動作中に変更が可能だった）ので、僕はこのシステムでもオブジェクトの処理を動的に扱う方法を探していたわけだ。例えば外国語にローカライズできる文字列やメニュー、画像などが、プログラマーでない人でもソースコードを再コンパイルせずに変更できるようにしたかった。それと同時に、僕が Finder で管理したかった種類のデータ、例えばアプリケーションや書類のアイコン、それからそれら同士の関連付けなどを処理するためにも、何らかのメカニズムが必要だったので、僕はこれらすべてを統合して扱えるようなものを考えていた。それで Finder の デスクトップ・データベースが生まれ、同時にそれを管理するためのものとしてのリソースマネージャも今日ある姿に結実していった、というわけだ。
それに、Finder からの必要性も、ファイルのメタデータを決定するための重要な要因だった。当初から僕には、ダブルクリックして書類を開くようにするために、各書類に対してそれを開くべきデフォルトのアプリケーションを指定するためのシンプルな方法が必要だと分かっていた。それと同時に、複数種類のファイルタイプを開けるアプリケーションもいろいろあるので、単純に１つのタイプごとにそのタイプのファイルすべてを開くようなアプリケーションを１つ対応させるようなことはできなかった。こうして、タイプコード（そのファイルの実際のフォーマット）とクリエータコード（デフォルトで開くアプリケーション、これは容易に変更できる）とが分離された。タイプとクリエータのコードを独立にファイルシステムに埋め込むことで、ファイル名をタイプ情報で汚染するという事態も避けることができた。この点は、我々のアプローチが他に比べて格段に勝っていると僕は感じていた。
デスクトップ・データベースとは、タイプ・クリエータの情報と、それを表現するアイコンとの結び付きのためのキャッシュだった。これはリソースとして保存された。各アプリケーションのバンドル情報、つまり書類のタイプと対応するアイコンの情報の結び付きを纏めた一連のリソースは、アプリケーションのリソースフォークに保存されるので、アプリケーションをインストールする際には単に必要なリソースをアプリケーションからデスクトップへとコピーするだけでデスクトップ・データベースが更新されることになる。こうした情報の重複、つまりタイプとクリエータの情報をディレクトリに、バンドル情報をアプリケーションのリソースフォークに、と分けて保存するやり方のお陰で、データベースの再構築がいつでも好きな時に、何物を失うこともなく実行できるようになった。このことが、初期の時代には重要なことだったんだ。
もちろん、リソースはプログラム外のデータ、例えばメニューやテキスト文字列などを分離して格納するためにも、非常に多く用いられた。そういうものをいろいろな国語にローカライズすることもできたわけだ。ResEdit を使えば、言語の専門家ならば、プログラムのソースコードにアクセスする必要なしに、アプリケーションの外国語版を手早く作ることもできるようになった。
僕はこのリソースマネージャの有用性を Andy Hertzfeld に説き付けた。その意義を納得するやいなや、彼は早速 Toolbox の大部分を書き直してリソースマネージャの利点を生かすように作り換えてくれた。その結果、ROM の容量も大幅に縮小できることになったし、アプリケーションを手軽にローカライズできる一般的な方法も手に入ったというわけだ。
Adam： ということは、Mac OS X で Unix 流のファイル名拡張子が導入されて、書類とアプリケーションの対応が拡張子に依存するようになったのは一歩後退したことになるのだろうか？
Bruce： それはイエスでもあり、ノーでもある。このことの背後にある元々の動機は、Mac OS X が Windows のファイル名の慣習と互換でなければならない、ということだった。だから、ファイル名の拡張子を導入することは絶対の要請だった。ファイルが Mac OS の聖所を出でて、残酷なる外界へと旅立つという機会が、ありとあらゆる場所で起こるようになったので、Mac の慣習（つまりタイプとクリエータ）を外界の慣習にいちいちすべて翻訳するということはもう不可能になってしまった。互換性に関して言うならば、これはこれで決まり、となってしまったのだ。
けれども時を経るにつれて、このことを正しく実行するのはとても難しいことだというのが次第に明らかになってきた。重複したタイプの情報を保存して、ユーザーに好きなようにファイルの名前を付けてもらう、という元々のメカニズムの方が、ずっと柔軟性があって間違いの可能性が少ないということに皆が気付くようになった。結局、Mac OS X ではやはり個々の書類ごとにそれぞれ特定のアプリケーションで開かれるようにするクリエータの情報がまだ必要だということで、この情報は、シンプルにクリエータコードとして保存するのではなく、何と、個々のファイルのリソースフォークに保存されることになった。（そこらじゅうのファイルそれぞれに、だ。Apple はリソースフォークの使用を止めさせようとしているというのに！）
というわけで、ファイル名拡張子の方法で動き出したのだが、ちょっとだけ元よりもエレガントさが欠けたかな、というところだ。
Adam： 最初の Mac の時点で、どうしてもっと徹底的に突き詰めて、こうしたデータをすべて扱えるシステムレベルのデータベースを作らなかったのだろう？ マシンの馬力の問題かな？ それとも当時ではソフトウェアの問題が複雑過ぎたのか？
Bruce： そういうものができたら良かっただろうね。確かにそんな感じのアイデアは僕も持っていたのだけれど、実際に 64K の ROM に収めようとなると、リソースマネージャだけでもう一杯になってしまって、それ以上のことはできなかった。誰もかれもがすごい努力をして、コードをできる限り小さくしようと必死だった。リソースマネージャは 3K、そして Finder は 46K だ。今どきのアプリケーションのサイズを考えれば、信じられないような数字だろう？
Adam： 君が Apple を辞めたのはいつで、その動機は何だったのだろうか？
Bruce： 僕が Apple 社を辞めたのは 1984 年の春で、Finder の“最終版”が完成したのを見届けてのことだった。たぶん僕は、何か新しいことをしたいと思っていたのだろう。Mac の開発に集中した仕事を何年も続けた後だったので、少し休みたいと思ったのかもしれない。Mac の開発チームの一員として、最高に素晴しい人たちと一緒に仕事をしてきたことは、僕のこれまでの人生の中でも一番のことの一つだし、今でもそういうことを思い出す度に僕の気持ちの中に暖かいものがこみ上げて来るくらいだ。
Adam： Apple を辞めた後、どんな仕事をしてきたのか、簡単に紹介してもらえるだろうか？ 取り組んだいろいろなプロジェクトには、何か共通の点があったのだろうか？
Bruce： Apple の後は、僕は Adobe に行って、いろいろの小さなプロジェクトを担当していた。例えば LaserWriter スプーラなんかだ。そこで働いていた間に、Carnegie Mellon 大学の卒業生二人と出会った。細かい話は飛ばすとして、彼らの説得で僕は Carnegie Mellon の大学院に行くことになった。（Adobe 創設者の一人の Chuck Geschke も、Carnegie Mellon の博士号を持っている。）大学院で学ぶのは素晴しい経験だった。その間研究助手として少しの間ノルウェーのオスロ大学で働いたり、時々は Apple でコンサルタントとして働いたこともある。そのうち、学生時代に温めていたおもしろいアイデアをふくらませて、それに取り組むチャンスを掴んだ。僕の博士論文は Siri という名前の、コンストレイントベースのオブジェクト指向プログラミング言語のデザイン方針を記述したもので、いつかはもう一度これを実現してみたいと思っている。
大学院を卒業した後は、Apple に Advanced Technology Group のコンサルタントとして戻り、LiveDoc というプロジェクトに取り組んだ。このチームでは Tom Bonura や Jim Miller も一緒だった。LiveDoc というのは自動的に内部構造の判定が付く書類の実験プロジェクトで、いろいろな認識子が書類を解析して、例えば 555-1212 が電話番号だとか 124 Main Street が住所だとか判定し、それぞれに応じたコンテクスト対応のアクションを引き起こす、というものだった。これはとても楽しい仕事で、現在の Mac OS X にも LiveDoc が実装されていたら、と思うこともよくある。現に Simson Garfinkel の SBook は、そういう機能のいくつかを PIM アプリケーションとして実現している。
でも、どのプロジェクトも僕が本当に解決したかった問題に正面から取り組むものではなかった。その問題というのは、あらゆるタイプの情報、例えば電子メールのメッセージから画像や音楽ファイルやその他の書類まで、すべてに対応した情報ブラウザというものを、一体どうすればデザインすることができるか、という問題だ。どうすればそういう情報をすべて整理して、検索し、表示できるような、普遍的なメカニズムが作れるのだろうか？
この問題に向けて、僕は 1997 年に iFile プロジェクトをスタートさせた。でもそれから２年ほど経ってから、このプロジェクトにはちょっとブレーキをかけて新しい自分の会社を始めることにした。それが Marketocracy、1999 年の半ばごろのことだった。
Marketocracy というのはミューチュアルファンドを扱う投資信託会社で、僕はビジネスパートナーである Ken Kam と共同でこの会社を設立した。僕たちのチームは Macintosh ベースのウェブサイトで WebObjects と FrontBase データベースを走らせ、世界中から 50,000 人もの人がリアルタイムで株を売買（ただし仮想のお金で）しながら株式ポートフォリオのモデルを作成できるようにした。多種多様なツールを提供してユーザーたちがより良いポートフォリオ管理者になれるよう手助けをし、長い時間間隔で彼らの成績を観察することで彼らに成績を付け、我がファンドを運営する能力世界一の人を表彰するのだ。我が Masters 100 Fund は、このコミュニティーのトップ 100 の人たちの実績から作ったものだが、今ではもう２年間を経て、その驚くべき成績とリスクの低さには我々自身驚かされているところだ。開始当初市場が基本的にフラットだった時と比較して、現在 39% を超えるリターンの実績を残している。ベータ値は何と 0.47 - これは市場の平均リスクの半分だよ！
<http://www.marketocracy.com/>
Adam： 現在取り組んでいる仕事は？
Bruce： 最近は、1999 年に中断していた iFile（今のところただのコード名だ）をもう一度取り上げている。iFile は統合化されたデスクトップ情報のブラウザで、ある意味 Finder と似ているが、構造上大きく進化したところがある。これは、僕自身がデザインしたオブジェクト指向のデータベースに基づいていて、このデータベースはあらゆるタイプのオブジェクトを互いにリンクさせて整理するための一般的な方法を提示しているのだ。整理のための基本単位は“collection”と呼ばれ、これがフォルダと何処が違うかというと、１つのオブジェクトはたった１つのフォルダにしか含まれ得ないのに対して、１つのオブジェクトが多数の collection の中に同時に存在することができるというところだ。この collection というのは iPhoto のアルバムや iTunes のプレイリストと似ているが、その中にどんなものでも含むことができる。テキストファイル、画像、電子メールのメッセージ、音楽ファイル、連絡先情報、メモ、面会予約、その他何でもだ。ちょっと BFS (BeOS Filing System) と BeOS Tracker を組み合わせたもののように聞こえるかもしれないが、これはそれよりずっと一般的で、適切なドライバさえあればどんなファイルシステムの上ででも使えるものだ。
iFile テクノロジーの最初の応用として誰でも考え付くのは、写真の整理だろう。これは、既に iPhoto がかなりうまくやってのけている。でも、iFile はそれよりもっと高度な能力がある。画像のメタデータによる整理（現在、個々の画像ごとに 46 種類の異なったメタデータを追跡できる）が可能だし、大きなサイズの collection に対しても iPhoto よりずっとスムーズにスケールの作業ができるはずだ。けれど、iFile は単なる写真管理のためだけのものではない。これは一般用の情報ブラウザであって、さまざまな用途に応用が効き、いくつもの情報源から手軽に情報を統合することもできる。PIM や電子メール、音楽、その他のデータタイプも受け入れるのだ。iFile を一般に公開リリースする頃には、こういった分野でもっと強力な機能を提供できるようにしたいと考えている。
Adam： すると、この iFile は、今もしも君が Finder を書いていたとしたらそうなっていたであろう姿、と言ってもいいのだろうか？
Bruce： そうかもしれない。現状では、元来僕が目指すつもりだったものよりも、ずっと曖昧なものになっている。これからもっとこれを絞り込んで、初めてのユーザーでも素早く理解できるようなレベルにまで高めることができたなら、そうすれば Finder の代替物としてもなかなかのものと言えるかもしれないね。
Adam： これを Apple の人たちに見せたことがあるのかい？ どういう感想だった？
Bruce： 1999 年の時点で、僕はこれをまず Finder グループの人たちに見せ、それから Avie Tevanian に、そして最後に Steve Jobs にも見せた。当時の Apple は、一刻も早く Mac OS X を門出させることに最大の力点を置いていて、Finder の代替物を探すなんていうことは優先順位が低かった。僕の感触では彼らは充分に興味を引かれたようだったけれど、既に会社は別の方向に身を任せてしまっていて、もはや iFile テクノロジーを取り入れるために船の進行方向を変えるなんて、出来ない相談だったようだ。Mac OS X の歴史を考えれば、僕は彼らが正しい決断をしたのだと思っている。
Adam： それでは、iFile についてもっと詳しいことに移ろう。どんなファイリングシステムでも、２つの側面があるはずだ。データを取り込むことと、そのデータをユーザーに表示して見せることだ。iFile にデータを取り込むのはどういう風にするのだろう？
Bruce： 現在のバージョンの iFile では、ユーザーがフォルダを指定して、そのフォルダを iFile が追跡することになる。これは、そのフォルダを iFile の workspace ウィンドウにドラッグすればよい。そうすると、その後それらのフォルダの内容に起こった変更はすべて自動的に iFile に認識されて、データベースが必要に応じて自動的に更新される。例えば、ユーザーが Pictures フォルダをドラッグするだけで、その後はファイルをコピーしたりどんなデータも動かしたりする必要もなく、すべての画像をブラウズしたり、collection を作成したり、といったことができる。iFile はあなたのディレクトリ構造を尊重して、（画像を自分のディレクトリ階層の中へとコピーする）iPhoto のように直接何かを変更するということもなく動作する。
iFile のリリース版になれば、ユーザーが特定のフォルダをスキャン対象として手で指定するような必要はなくして、その代わり、iFile は初めユーザーのホームディレクトリの表示からスタートし、バックグラウンドで自動的にファイルやフォルダのスキャンを実行するようにするつもりだ。
Adam： それは素晴しい！ ユーザーの手間が少なくて済めば済むほど、なおさら良いものになる。実際、どんなファイリングシステムにしても、最大の問題点の一つは、たいていの人がデータの整理や管理に充分な労力を掛けないために、あとで必要なものを探そうとしてもうまく見つからないということだから。それで、iFile はメタデータやファイル内容に基づいて自動的にファイルをカテゴリーに分けてくれるのだろうか？
Bruce： うむ、それはできる。そもそも、collection というのはファイルをそのプロパティに基づいて自動的にカテゴリー分けするための一つの方法なのだから。iFile はファイルのメタデータをオブジェクト・データベースの中で保持するので、メタデータの検索やソートもとても高速で、欲しいファイルをたちどころに返してくれる。また、collection は“ライブ”でもある。つまり、ディスク上にその collection の条件に適合するファイルが現われれば、そのファイルは自動的にその collection に追加される。その collection が現在表示されているかどうかには一切無関係に、だ。こうしたイベントに基づいていろいろなおもしろい AppleScript スクリプトを走らせることもできるだろうし、いくらでも応用は思い付くだろう。
また、collection はファイル内容に基づいてファイルを収集することもできる。Google のように個々の単語ごとの検索を走らせるのではなく、collection はキーとなるフレーズ、つまり単語でも文でも検索できる。collection で指定されたキーフレーズのどれかを内容として含むファイルはすべて、自動的にその collection に集められる。
というわけで、collection とは、あなたが既に持っている情報を別のやり方で切り分けて並べ直すための、新しい手段なのだ。それも、いちいちあなたがデータを読み込ませたり全く新しい整理基準にはめ込んだり、といった手間は要らないのだ。
Adam： ベイジアン分類のような、ファイル内容を統計的に評価する機能を追加するというのはどうだろうか？ 例えばスパムフィルタとか、電子メールを分類する POPfile プログラムのように使うわけだ。そうすれば、ユーザーの仕事をもっと減らしてくれると思うのだが。
Bruce： それは素晴しいアイデアだと思うし、実際かなり前から検討している。現に、Apple もこのアイデアに基づいたプロジェクトを進めたことがある。Piles というのも、ファイル内容によって自動的にファイルをグループ分けするものだった：
<http://www.theregister.co.uk/content/archive/30360.html>
ただ、ここで一つ大きな問題があって、それは適切な類似性関数を決定できるかということだ。その collection がどういうものであるべきかを、どうやってあらかじめ決められるのだろうか。それぞれ１個ずつしかファイルを含んでいない collection が何百も出来たり、反対に何千ものファイルを含んだほんの少数の collection に分かれるだけだったり、という事態をどうやって避けるのか、という問題だ。これを解決するにはかなりの努力が必要だ。
Adam： では、iFile のもう１つの側面、データをユーザーに表示して見せる方はどうだろうか？ ユーザーが自分で“スマートフォルダ”（iTunes のスマートプレイリストのようなもの）を作って、特定の基準に合致するファイルを自動的に一覧できたりするのだろうか？
Bruce： その通り。collection は基本的には、検索基準を明示したスマートフォルダだと思ってよいだろう。例えば、ある特定の機種のカメラで撮影した写真だけを集めた collection を作ろうと思えば、“<model> が '2500' で <make> が 'Nikon'”と指定すればよい。これらのデータは EXIF メタデータとして画像の中に保存されているからだ。音楽ファイルの ID3 タグや、解像度・横幅・高さなどの画像データ、ファイル名・作成日時・変更日時・サイズなどのファイルデータ、その他の情報も、同じようにデータベースに保存してオブジェクトの検索や整理に使うことができるだろう。
結局、collection は実際３種類のメカニズムを使ってグループ分けができる。手動でのドラッグ＆ドロップ、メタデータによる検索基準での自動振り分け、それからキーフレーズによる自動検索だ。
Adam： iFile のアーキテクチャはすごく魅力的なものだと思うけれど、見たところ細かい部分にこそ悪魔が隠れている、という感じだね。特にインターフェイスが問題かもしれない。iFile は、現在のファイル・フォルダのメタファを（用語は collection というものに移行するとしても）使い続けるのだろうか？ それとも、僕たちがデータを扱うやり方までも考え直したものになるのだろうか？
Bruce： うむ。細かい部分にこそ悪魔が隠れている、という点は正しい指摘だね。現在、僕はこの情報すべてをどうやって表示するか、どうすればうまく直観的な仕方で表わせるか、というところに取り組んでいる。今、かなり目標に近づいて来ているとは思うのだが、もちろんまだまだやらねばならないことが残っている。
iFile は、伝統的なアイコンベースのファイルとコンテナによる構成からスタートする。（コンテナとはフォルダあるいは collection のことだ。）だがそれはそこに止まることなく、さらにいろいろの違った表示法やレイアウトも持つ。そのレイアウトの多くはファイル内容のプレビュー表示を持っていて、テキストファイルの場合には、iFile が自動的にそのテキストの中から関連ある collection へと結び付くハイパーリンクを作ってくれる。言葉で説明するのは難しいけれど、一度 iFile を使ってみれば、いくつかの表示法を使ってあなたのデータをいろいろの異なった視点から観ることができるのだ、ということが実感してもらえると思う。
自分のデータをどのように観たいのか、という情報をたくさん iFile に与えれば与えるほど、つまりいろいろな collection を定義すればするほど、iFile は相互参照を深めて、あなたがそれまで気付かなかったような相互関係までをも浮き彫りにしてくれるはずだ。
Adam： 君が iFile に盛り込もうとしていることのいくつかは、大多数のユーザーが理解できる範囲を超えているのではないだろうか？ たいていの人にとっては、言われたことをそのままやるだけというのが普通で、iFile が持つ柔軟性は、ユーザーの動作をフォローして自動的に collection を作成するようにでもしない限り、そういう人たちには届かないかもしれないのでは？
Bruce： 確かに、新しいユーザーにとっては iFile は何となく恐ろしいものに見えることがあるかもしれない。iFile にはいろいろの違ったことがたくさん出来るし、ユーザーが使う時にもっと直接的な反応を表示することも必要だろうと思う。君の言う通り、自動的に collection を作成するのは良いアプローチだし、画像だけでなく書類や電子メールなどについても使いやすい collection が自動的に作れるようになれば、このテクノロジーの持つパワーを多くの人にもっと実感してもらえるようになると思う。これから数ヵ月以内に、そういうアイデアのいくつかを実装する予定だ。だから、期待して待っていて欲しい！ こういうテクノロジーに興味があって、公開バージョンが完成した時に連絡を貰いたいという人は、下記のサイトにサインアップして頂ければ、最新の情報をお知らせするようにしたい。また、いつか TidBITS に、リリース版の詳細について説明した記事を書かせてもらえれば嬉しい。
<http://www.ingenuitysoftware.com/>
Adam： Bruce、大変おもしろい話をどうもありがとう。我々みんな、君がこれからどんな iFile を作り出してくれるのか、わくわくしながら待っている。ひょっとしたら、今の Apple は Mac OS X を安定なものに仕上げたところなので、次の一手として、君の今回の仕事の成果にも、注目の目を向けてくれるかもしれない。
文： Brady Johnson <[email protected]>
訳： 亀岡孝仁 <takkameoka@earthlink.net>
訳： 倉石毅雄 <takeo.kuraishi@attglobal.net>
あまりパッとしない話である。私はこれまで何度か TidBITS にスパムについての記事を書いてきたが、回を重ねる毎に残念ながらスパム量の統計を増加方向に修正してきた。私はいつも Brightmail や他のサイトに行きその努力がこれまでどの程度効果を上げているかを見ることから始める。ただ悲しい話だが、結果が良かったためしはない。連邦議会ですら法制化に当たって、この悲しい表現を CAN-SPAM Act の冒頭部分で取り上げた：“2001年には 7% と見込まれていた勝手に送りつけてくる宣伝用電子メールは、現在、全電子メール量の半分を超していると見込まれており、その量は増加の一途を辿っている。”
<http://db.tidbits.com/getbits.acgi?tbser=1169>
(日本語)
メールスパム：宣伝カーは鳴りやまず
メールスパム：宣伝カーは鳴りやまず（第 2 部）
対スパム用ツールをもっと
スパムが非合法になれば、ただ無法者だけがスパムする
事実、Brightmail によれば、スパムは猛暑の夏の日の水銀柱よりも早く上昇を続けている。2002年には、スパムは全メールに対して 40% と見込まれていた。と言うことは、もし連邦議会の 7% と言う数字が正しければ、2001年から 2002年にかけての増加率は 600% に近いということになる。この数字は、2003年の終りまでに 58% にまで増えた。このまま行けば、2004年の終りまでには我々のメールの 65% はスパムだと言う勘定になってしまう。
<http://www.brightmail.com/spamstats.html>
この流れを止めるために、連邦議会は“Controlling the Assault of Non-Solicited Pornography and Marketing Act (希望しないポルノ及び商業宣伝からの攻撃を規制する法)”或いは別名 CAN-SPAM を法制化した。16-Dec-03 には Bush 大統領もこの法案に署名し正式な法となり 01-Jan-04 に施行された。
<http://www.spamlaws.com/federal/108s877.html>
CAN-SPAM は多くの論議論争を巻き起こした。ネットワーク関連者の多くはこれを悪魔との取引きだと怒りを込めて酷評し、商業関係者はスパム退治の戦いに向けて前向きな一歩だと賞賛している。
CAN-SPAM に関する色々な論評を見ていると、この意見の食い違いの大元は“スパム”の定義にあると言うことがすぐに見えてくる。多くの通常のインターネットユーザーにとっては、“スパム”とは送り主が誰であれ勝手に送りつけてくる宣伝メールを含む。これらのユーザーにとっては、CAN-SPAM はスパムのほんの一部だけを相手にしており逆にその他を合法化してしまっていると見える。商業界やその他の人は、大量メールと言えどもそれが誤解を招く恐れのあったり欺瞞的でない限りは、商業的言論の自由の正当な権利行使であり、郵便のジャンクメール以上に問題とされるべきものではないとしている。従って、彼らの立場はこの様なメールは“スパム”の定義に含まれるべきではないという事である。この様なユーザーにとっては、CAN-SPAM は大きな前進の証と見なされる。
それでは “スパム”とは一体何者か？ 私はまず、スパムとは実際 Hormel という会社が出しているピンクがかった肉製品のことである事をお伝えしておく義務感を抑えられない。Hormel は遅まきながらその商品名をこの様な悪名高いメールに使われることを問題にし始めており、"spam”と言う表現を含んだ商標、例えば SpamArrest のような、の使用を差し止めようとしている。
<http://abcnews.go.com/sections/scitech/Business/techtv_spam030801.html>
しかしながら多くの人にとっては、“スパム”とは単に見知らぬ人からの望まないメールであり、商品を売りつける、地位を押し売りする、商業 Web サイトを宣伝する、或いはあるリーダーの意見を別の方向にそらすといったことのためのメールを指す。色々な州で、反スパムの法制化が広がるにつれて、その定義は変態し縮小化し、政治とか慈善のための勧誘のような非商業的なメールは例外とする“unwanted commercial email (望まない商業メール)”或いは“UCE”まで来ている。CAN-SPAM ではこの定義を更に狭くしている。
CAN-SPAM では、“スパム”という言葉はそのタイトルの呼称として、或いはまた初期の recitation（表現）の一つとしてしか使われていない。(法における recitation(表現）と言うのは法的拘束力は何も持たず、単に法廷においての判断を助けるために法の趣旨を説明したものである。) CAN-SPAM では、"商業的電子メールとは、その主目的が商業製品やサービスの商業的宣伝か或いは販売促進であるような、電子メール" と定義づけている。政治的或いは慈善のための勧誘はやはりこの定義から除かれており、そしてまた“取引に係わる或いは又関係のあるメッセージ”も除外されている。これはあなたが何らかの既存のつながりを持った相手からの電子メールメッセージのことを言っている。
CAN-SPAM は Federal Trade Commission (FTC) に“取引に係わる或いは関係のあるメッセージ... の定義を、この法の目的を達成するために必要であれば、電子メール技術や慣行の変化に対応して変更する権限を与えている。しかしながら、“商業的電子メール”の定義を変える権限を FTC は与えられていない。
主たる CAN-SPAM 条項 -- CAN-SPAM の最も厳しい禁止条項はある種の欺瞞的で不正なメールに焦点を当てている。これに該当すれば、スパマーは相当な刑事罰の対象となる。初犯の場合で刑務所に三年、再犯また他の重犯罪の引き金となる虚偽の商業メールに対しては五年である。これに当てはまる例としては、亡命政治家からのメールで、隠し資産の合法化に力を貸してくれる人を求める、分け前は大きい、助ける意思のある人はまず有効な銀行口座番号を折り返し教えてくれと言ったものがある。これらのメッセージは、すでに現行の刑法の元での立件の対象となっているが、CAN-SPAM の元でも更なる犯罪として扱われる。
他の刑法犯としては、商業メールを送ったり、リレーしたりするためにコンピュータ、サーバー或いはドメインを合法的な所有者の許可なしに使うこと、そして偽のヘッダーや誤解を招く題名を使うことも含まれる。これらの行為は、刑事訴訟に加えて更に民事での訴訟や賠償の対象ともなる。
CAN-SPAM は自らの意思で配信から抜けられるモデルを用いている。これによれば、全ての商業メールはこの送信者からの将来の配信を中止できる方法を提供しなければいけないこと、それに送信者の本当のメールアドレスと郵便でのコンタクト情報を含まねばならない。この法はスパムは具体的に、受信者が抜けるために使える mailto、Web リンク、或いは他のオンラインの仕組みを持たなければならないと規定している。CAN-SPAM の定義に該当する全ての商業メールは自らを宣伝であると明示する義務を負っている。法自体はスパマーが自己のメールをどの様に自己表示（ID ）するのかまでは規定していず、それを FTC の手に委ねた。FTC には、スパマーが用いなければいけない ID マークを公開する期限として April Fools Day (01-Apr-04) までが与えられている。他の CAN-SPAM 条項のように、この ID 規定は、メッセージを受け取ることに対してはっきりと同意している人に対して送られるメールには適用されない。
CAN-SPAM は、ある種の行為をより厳しい罰に処するべき“悪質な違反”と見なしている。これらには、色々なインターネットのソースからメールアドレスを刈り取ってきたり、"辞書攻撃”を使ったりするよく見られる行為が含まれる。他人のサーバーをハイジャックすることも悪質な違反である。
この法の最も批判を浴びているところは、スパムに関する全ての州法にある非常に限られた例外を除いて取って代わってしまう条項である。この空洞化を生き延びられた州法は、商業メールでの虚偽や欺瞞を禁止する Washington 州法や California 法の大部分だけで、それもたまたま電子メールにも波及するものに限られる。たまたまメールにも波及する法の例としては、一般的なコンピュータ不法侵入法、消費者保護法、それにその他の法で時にはメールも含む行為に適用されるものがあげられる。と言うことは、多くの現存する州法は路傍に追いやられてしまったし、今年施行となった California の事前承認法も実効的には殆ど無効とされてしまった。
法の執行に関して、CAN-SPAM は個人の訴訟権を認めていない、つまりスパマーの犠牲者個人が法廷に行ってこの法律違反だと訴訟を起こすことは出来ない。法で定めた執行官は、FTC とその他の連邦政府機関、州の検事総長、それにインターネットサービスプロバイダ（ISP）である。ISP はメールやスパムに関してしばしば独自に設定した許される使用基準を持っていることも頭に入れておきたい。この新しい連邦法はこれらの民間の基準を妨げない、つまり ISP はその基準に基づいて違反者に対して、契約の解除、停止、そして損害の賠償を請求する等々の権限を保持している。ISP 権限をそのまま残したことで、スパマーに対する責任追及、それが稀にしか使われないとしても、に対する独立した基盤が存続することとなった。
CAN-SPAM は効果があるだろうか? 残念ながら答えはノーだろう。CAN-SPAM はま ともな最初の一歩かもしれないが、私の意見としては、あまりにも欠点が多すぎてス パムをやめさせるどころか、減らす効果すら無いだろうと思う。
CAN-SPAM の良い点としては、連邦法であるため合衆国中で等しく適用される点があ る。反スパム法律を立法した州の異なる法の混乱を招くツギハギな状況を直す。ま た、州がその境界の外にあるビジネスに対して権限があるのかという司法上の疑問点 の解決に非常に役立つ。このような司法権限の問題は州レベルでのスパム取り締まり 上で非常に多かった。
また、多種の“違法行為”が明示され、法文化されたのは非常にあり難い。何が違法 かがはっきりすれば、検察官による追及が楽になるからだ。
また、スパム送信者の賠償責任が増える可能性があれば、スパムに対する経済的なバ ランスが少しは是正されるだろう。もしスパムの送信が禁固につながりうるのであれ ば、送信者らは報酬がリスクに見合うものか考える必要がある。逮捕されなければ法 律上の義務や禁止条項を無視するような連中には新しい賠償責任は何らの影響も無い かもしれないが、禁固や罰金などの罰則の可能性を高くすれば、これまで違法すれす れの行為を検討していたビジネスはおそらく用心してやめるだろう。
だが、このような点にもかかわらず、CAN-SPAN の欠点は多数ある。いくつか検討して みよう。
国際的な問題 -- 残念ながら、CAN-SPAM はアメリカ合衆国でしか通用しない。確 かにアメリカの法律と国際条約はアメリカに影響を及ぼす問題に関してアメリカの法 廷に権限を与えている。だが、一見役に立ちに見えても、二つ大きな問題がある。
まず、実際の取り締まりの問題がある。アメリカの外にいるスパム送信者はアメリカ の法廷に縛られない。もし縛られるとしても、実行されなくては判決も命令も何ら意 味が無い。これはつまり、取り締まり機関が海外の送信者を法律に従わせるには外交 的な圧力を加える以外に無いことを意味している。ではスパムの法律を実効力がある ものにするのがアメリカの外交的な努力の重要目的になるとと思う人は何人いるだろ うか？もしスパムの送信者がテロリスト集団の一部だと証明できれば話は違うが…
第二に、CAN-SPAM の自らの意思で配信から抜ける (オプトアウト) 方針は先進国のほ とんど - もしかしたら他のすべて - の国で取られている方向と食い違っている。 European Union は自らの意思で配信を依頼する (オプトイン) 方針を確立する Directive (方針書類) を採用している。それぞれのメンバー諸国は Directive を実 行に移す特定の法律を立法しなくてはならない。(下記の最初の URL は Directive の 英語版に行く。第二の URL は他の言語だ。)
<http://europa.eu.int/eur-lex/pri/en/oj/dat/2002/l_201/l_20120020731en00370047.pdf>
<http://europa.eu.int/information_society/topics/ecomm/useful_information/library/legislation/text_en.htm#dir_2002_58_ec>
またオーストラリアも国民に対して商用メールの送り付けを広く禁じているオプトイ ン法律を採択している。簡単に言えば、多くのスパムがアメリカから送信されるか、 アメリカの会社の商品やサービスを売り込んでいるようだ。だが、技術的に発展した 世界での選択はオプトインに向いているようであり、アメリカだけが世界の他の国と は違った方向へ向かっているように見える。
このような異なった方向は、アメリカで連邦の法が採択される前の州ごとに異なった 規則や基準があった頃の問題と似ており、場合によっては状況をさらに悪化させるだ ろうと思われる。アメリカでは、少なくともどの州も同じ連邦の法律に縛られ、一般 的な法律的な分析と解釈が適用される。だが、国際的には、このように大きく異なっ たスパム対処方法があると問題はもっと難しいだろう。アメリカの法律の方が制限は 少ないため、EU 諸国やオーストラリアは自国では違法なものの、アメリカでは合法な スパムの怒涛が減ることはないだろう。
オプトアウトの問題 -- オプトアウトの方法を選んだのは不運だった。これは受 信者が送信者に連絡して今後のメッセージを送らないよう、依頼する必要がある。機 能する返信アドレスや Web リンクを含んでいる合法的なマーケッティング会社なら良 いが、多くのスパムは合法的ではないし、そのようなリンクの使用はメールアドレス の確認や収穫のために悪用される場合の方が多いだろう。このようなオプト-アウトの リンクの使用を促すことで、CAN-SPAM は逆に違法なスパムの量を増やしかねない。ま た、このような問題に疎いネットユーザに対する身分詐称や他の犯罪の危険性を増や す可能性もある。
取り締まりの問題 -- CAN-SPAM は取締りの任務全てを連邦や州の警察機関に押し 付ける。だが彼らは既に多すぎる仕事を抱えており、スパムの取締りを最重要案件に する気配は無い。ISP が何らかの行動をとるだろうとは思うが、多くの ISP は他国の スパム送信者を追跡したり、裁判をサポートするだけの人員も予算もない。
もっとも、CAN-SPAM 以前は、多くの取り締まりは個人レベルで行われる必要があり、 それも多くは反スパム法律の無い州でだった。多くの個人は ISP ら以上に完全なスパ ム調査の費用など出せない。だが CAN-SPAM は違反者に対して個人が民法裁判を起こ すことを許可していない。個人の取締りを許さないのは逆効果のように思える。スパ ムとの戦いにおいて手助けとなるだろうし、送信者が特定できて責任をとらせること に成功すればスパムの本当の被害者 - 個人のユーザ - に損害賠償をもたらすはずな のだから。
最後に、もしスパム送信者が法廷に引きずり出されたとしても、CAN-SPAM の抜け穴の ために威力を発揮しないかもしれない。例えば、スパムの“主要な目的”という項目 を活用すれば、送信者が個人的な手紙をも含み、同時に何かを売りつけようとした場 合、販売がメールの“主要な目的”ではないと主張できる。この記事を読んでいる人 の多くは“やあ！元気かい？自分も元気だよ。そう言えば、こんな商品 <製品名> を 見かけたんだけど、興味あるんじゃないかと思って連絡したんだ。”といった文面の メールを受け取ったことがあるに違いない。このような曖昧さは法廷で笑い飛ばされ るかもしれないが、実際に法廷で明確にされないことにはその影響が読めないだろ う。その結果、検察が裁判官にこの質問を問い質し答えが出るまでは、この法律の恩 恵を受けるのがさらに遅れてしまう。これも個人の取締りが有用な理由の一つだ。検 察よりも個人や消費者団体の方がこの問題を取り上げるのが早いだろうと思えないだ ろうか？
まとめ -- 以前の記事では、スパムが違法とされたら無法者しかスパムを送らな いだろうと書いた。既存の州の法律に違反しているスパムの数は増えつつあるが、違 法とされたからといって消えるどころか減る気配もない。合法的な会社は法律に従っ ているが、法律を無視している虫けらどもは新しい法律もまったく気にせず破ること だろう。やめさせるには実際に身柄を拘束するしかない。
最終的な分析としては、CAN-SPAM は良い出発点と言えよう。だがスパムに対する道具 としてはあまりにも欠点が多すぎる。州の法律同様、合法的な会社がスパムを活用す るのを防ぐだろう (今までに合法的な会社がスパムをそんなに送っていたわけでもな い)。だが、アメリカの司法の手が及ばない海外の送信者や逮捕されなければ法律を無 視するような送信者には全く影響が無いだろう。他国の反スパム法律との食い違い は、アメリカからスパムを送信することによりそれらの国でのスパムを抑えようとい う努力を妨げることになるだろう。
はっきり言えば、CAN-SPAM はスパム送信者に対して法律の大きな抜け穴を通りさえす れば好きなだけメールを送ってよいと許可を与えているのだ。一番失望した点は、こ れまで連邦政府の反スパム法律を何年も待っていたにもかかわらず、その結果出てき たものは全然不十分で、無効化された既存の州の法律よりも悪いものだったことだ。 これは非常に残念なことで、私たちは当分の間、その問題と共に暮らしていかなくて はいけないだろう。
[Brady Johnson シアトルに住む文句の多いな弁護士で、本当に本当にスパムを嫌 っている。]
文： TidBITS Staff <[email protected]>
AppleWorks の国際版 -- 最新の AppleWorks アップデートが Apple からリリースされた時あまり明確にはされなかったのだが、実は同時に国際版もアップデートされていた。（ただし、フランス語版だけはまだアップデートされていない。）(メッセージ数 2)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2145>
Habeas に攻撃が殺到 -- Habeas がスパムに対する戦いを始めて以来、最初の深刻な試練に直面している。Habeas は、うまくスパム発信者を特定して、彼らの俳句のヘッダに関わる著作権と商標権を侵害した罪で告訴することができるだろうか？ (メッセージ数 5)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2144>
Apple からオーディオ製品のフル・ラインアップ -- Apple が最近力を入れているオーディオ関係のアプリケーション（発表のみでまだリリースされていないプログラムも含む）は、Apple 社に対する消費者の、またオーディオコミュニティーの受け取り方に、どんな影響を与えているのだろうか。(メッセージ数 2)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2143>
iPhoto 4 の第一印象 -- 何はともあれ、iPhoto 4 で速度が向上した点は、誰もが認める iLife '04 のベストな改良点の一つだ、というのが読者たちの意見だ。(メッセージ数 2)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2142>
非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
, 
日本語版最終更新：2005年 12月 26日 月曜日, S. HOSOKAWA