Mac関連ネタを凄い勢いで翻訳するスレ5

Mac関連ネタを凄い勢いで翻訳するスレ5 at MAC

1:名称未設定
05/05/17 06:18:31 90rwwCgG
前スレ
Mac関連ネタを凄い勢いで翻訳するスレ・４
ｽﾚﾘﾝｸ(mac板)

Mac関連の英文記事や英文マニュアルなどを、暇な人たちが翻訳するスレッド第四弾です。
「この英文の内容を知りたいんだけど、自動翻訳じゃ意味がｻﾊﾟｰﾘ」という場合に
活用してください。

＜＜依頼者へのお願い＞＞
◎翻訳する人はあくまでボランティアです。以下の点にご注意下さい。
・訳文の二次利用はご法度です。
・ご自身のサイトの翻訳はご遠慮下さい。
・あまり長すぎる文章を依頼しないように。
・翻訳してくれる人への感謝の気持ちをお忘れなく。

［過去スレ］
Mac関連テキストをすごい勢いで翻訳するスレッド
URLﾘﾝｸ(pc.2ch.net)
Mac関連ネタを凄い勢いで翻訳スレ2（dat落ち）
ｽﾚﾘﾝｸ(mac板)
Mac関連ネタを凄い勢いで翻訳スレ3冊目
ｽﾚﾘﾝｸ(mac板)
Mac関連ネタを凄い勢いで翻訳するスレ・４
ｽﾚﾘﾝｸ(mac板)

2:名称未設定
05/05/17 06:21:18 QcUOXUeV
第五弾ね

3:名称未設定
05/05/17 08:36:38 LhciLf+j
3333333333

4:English translation
05/05/17 09:18:56 xBJr1k3Q
Previous Thread
The thread of translation about Mac No.4
ｽﾚﾘﾝｸ(mac板)

This is the thread No.4, in which someone who has enough time to translate contents about Macintosh.

You can use this thread , when you feel like this.
"I wanna know what that website said.. I already tried web translation, but it sucks !"

<< Read first before ask to translate >>

* Translation is totally based on mind of voluntary.
You have to
* don't use translated text anywhere besides here.
* don't translate your own website.
* don't ask to translate too long texts.
* don't forget to appreciate to translater.

[ Previous Threads ]
The thread of translation about Mac
URLﾘﾝｸ(pc.2ch.net)
The thread of translation about Mac No.2 (in dat)
ｽﾚﾘﾝｸ(mac板)
The thread of translation about Mac No.3
ｽﾚﾘﾝｸ(mac板)
The thread of translation about Mac No.4
ｽﾚﾘﾝｸ(mac板)

5:English translation
05/05/17 09:20:38 xBJr1k3Q
別に意味はないんだけど暇だから翻訳してみた。

6:名称未設定
05/05/17 09:30:24 F9AN0R2m
なにか妙な笑いが

7:名称未設定
05/05/17 10:04:10 hquaRVS7
* All your base are belong to us.

8:名称未設定
05/05/17 10:18:06 XtGnmd1C
>>7
以前にネットサーフィンの最中それにハマったんだけど、
あれもぼくの英語力じゃなにがおもしろいのかイマイチわからんかった。
ただし、悪いが>>4のあとに>>7を書くおもしろさはわかるw。

9:名称未設定
05/05/17 13:58:33 xS9LTG6g
URLﾘﾝｸ(24hour.system.to)

一応ここに解説があるが、俺もこれがどう面白いのかはわからない。

10:名称未設定
05/05/17 16:41:14 X7fjDALu
くだんのMac.arsのSiracusaのレビュー、Finderの章をやってみます。(全10回)

Finderの（不完全な）更新

本記事のメタデータの項（なんか随分昔のことのような気がする）で、メタデータの話題については
「Mac OS Xのメタデータの機能の進化は停滞している」と述べた。ある意味では、言いたいことは
すべて言い尽くしており、残されているものは希望だけなのだ。ただそれははっきりしないものであるが。

Tigerの導入とともに、Mac OS XのFinderはその段階に入った（訳註：これ以上進化させようがない）。
TigerのFinderは、Spotlightの追加以外には目立ったインターフェースの機能追加／変更を受けていない。
そして、これまで見てきた通り、こうした進化の余地のないものであっても、いや、だからこそ、Finderに
対するイライラが募るのである。

Mac OS XのFinderは、何年もかけてそれに相応しい評価（少なくともMac OS Xのバンドルアプリ
としての）を得てきた。これはMacプラットフォームで最も使用頻度の高いダメソフトと言われてきた。
このFinderの流儀を好む者もいるが、大好きという者はほとんどおらず、嫌いな人は多い。

Mac.arsのMacintoshian Achaiaフォーラムでは"FTFF"という略称はもう説明なしに使われている。
"Fix the F***ing Finder"（あのクソFinderをどうにかしる！）の略だ。この言葉はMac OS Xのウィッシュ
リストのスレにしょっちゅう出てくる。（長々と私がFinderを批判していることがフォーラムでの意見に
バイアスをかけていると感じる読者がいるとすれば、その人はMacintoshian Achaiaをよく知らない人だろう）

カジュアルなオブザーバーにとっては、ちょっと極端な意見だと感じるかもしれない。Mac OS XのFinderは、
グラマラスではないにしろ、少なくとも害のないもののように思えるからだ。では何が大問題なのか？
Finderに対する悪印象の出どころは一箇所ではないのだ。Finderに対する不満をぶちまけるスレは少なくとも
３つあり、通常はFinderの特定のダメさ加減が複数組み合わさったものとして出てきているのだ。

11:2/10
05/05/17 16:42:06 X7fjDALu
まず、私のPantherレビューで詳述したブラウザ空間としての全体的な問題がある。この件については
単独のレビューも書いた。ここではその問題を繰り返すつもりはない。PantherのFinderについて2003年に
私が書いたことは現在のTigerのFinderにそのまま当てはまる、と言えば十分だろう。

第２の問題点はパフォーマンスである。旧Mac OSのFinderは、高負荷時やネットワーク接続時にもレスポンシブ
さを保てるかという点においては平凡であった。だが今のスタンダードは当時とは違う。Mac OS X時代に
求められるものはもっとずっと高いものなのだ。だが悲しいかな、Mac OS XのFinderは当時から停滞したまま、
すなわち前時代的なものなのだ。

Motionのようなアプリがリアルタイムで複数のビデオストリームの編集ができるというのに、Mac OS Xの
FinderのUIときたら、多数のファイルを別の場所にドラッグしようとするといまだにつっかえるのだ。
アプリケーションレベルでの「一時停止」（かの悪名高きビーチボールぐるぐる）の原因は、未だにあの
ネットワークアクセスにあるのだ。ネット上のMacのフォーラムでは、たとえばカラムビュー時にネットワーク上の
ボリュームにあるQuickTimeファイルをうっかりクリックしたとき、「親切にも」プレビュー画面を表示
しようとしてFinder全体が止まってしまうというような悪夢の話で賑わっている。それからiDisk・・・頼むから
iDiskの話をさせないで。もう論外の遅さなんだから。サードパーティーのWebDAVクライアントが何の問題もなく
.MacのiDisk上のファイルの読み書きができるというのに、Finderときたら一時停止状態が長いわデータの
転送速度は遅いわ、という有様なのだ。

FinderのパフォーマンスはMac OS X 10.0以降着実に進化しており、時に大きな進化も受けている。
しかしそれは「使えない」レベルから「ストレスがたまるくらい遅い」レベルに達したというだけのことで、
決して威張れる話ではない。これは実際の問題の大きさの話ではない。OKレベルのこともある。だが他の現代の
アプリと比較したとき、Finderが抱えるパフォーマンスの問題は大きいのだ。

12:3/10
05/05/17 16:43:09 X7fjDALu
そこでMac OS XのFinderに対する不満の最終段階にたどりつく。それはちょっとしたことなのだ。
バージョン1.0の製品ならちょっとしたイライラは見逃すこともできよう。最初のMac OS XのFinderなら
そういう話も有効であっただろう。だがそうしたイライラを、比較的簡単に解決できる問題なのにもかかわらず
4年間も引きずってきたとなれば、そりゃ皆さん腹も立とうというもの。

例を挙げればキリがない。そして全部挙げたところでフォーラムのスレの中の人を止めることはできないだろう。
ここでは私の経験から３つほど挙げよう。

一つはアイコンのグリッド配列。そもそもMac OS XのFinderはアイコンのグリッド間隔がやたらに広い。
これは長い名前のファイル／フォルダ名を折り返させないという利点があるものの、ユーザーの多く
（特に小さな画面で使っているユーザー）は、一般的な長さのファイル名のファイルを扱う場合には
無駄が多いと感じるのだ。

アイコンのグリッド間隔の調節オプションについてはMac OS X 10.0の頃から要望があったにも拘らず、
未だに実装されていない。10年以上前に旧Mac OSのFinderが簡易的にグリッド間隔を調節できる機能を
実装していただけに、余計腹立たしいのだ。（技術はある、作り直せるのだ！）

それから「表示オプション」のパレット。パレット内でのビューに変更を加えるラジオボタンがついている。
加えて、適用範囲を「このウインドウのみ」「すべてのウインドウ」とするラジオボタンがある（Mac OS Xの
Finder上で「すべてのウインドウ」に適用するというオプションは残酷な冗談であるという事実はこの際
忘れてしまおう）。ユーザーがこのパレットを呼び出すときは、今見ているウインドウのビューの変更を行いたい
からそうするのである。まあ1000回に1回くらいはFinder上の「すべてのウインドウ」に適用を行いたくなる
のかもしれないが（どんな意味があるか知らないが）、99.9%の場合は単にウインドウ一枚だけに変更を適用
したいものだろう。

13:4/10
05/05/17 16:43:44 X7fjDALu
腹立たしいことに、この「すべてのウインドウ」は大抵の場合デフォルトで選択された状態になっている。
（どの条件においてどちらのラジオボタンが選択されているかというのは、まったく運任せなのだ）
すなわち、ユーザーがある特定のウインドウのビューを変更したい場合、事実上毎回、くだんのラジオボタンの
切り換えを行わなければならないのだ。これはひどく時代遅れなものではありませんか。

最後に、タイトルバー上の緑のボタンをクリックしたときのFinderウインドウの「サイズに合わせる」
挙動について。理論的には（実際には、この機能を有する旧Mac OSのFinder全バージョンも）Finder
ウインドウはウインドウ内の項目をできる限り多く表示し、かつ余分なスペースをなくした状態にリサイズ
されるはずある。アイコンがいっぱい詰まったFinderウインドウについては、アクティブなスクロールバーの
ないウインドウとなるはずである。

ところがMac OS XのFinderでは、昔も今も、この機能がまったく一貫していないのだ。上手く動作しない
ときは、5ピクセルしか動作幅のないスクロールバーが表示されたりする。Finderはウインドウのサイズを
適切にリサイズしようとするが、アイコンの占める領域を正しく判定できないのだ。途方もなく難しい
技術ではないはずなのに・・・。

これらはノミ取りが完全に行われていないような印象だ。「残念、ペットのノミを取りきれませんでした」
という感じだろうか。しかし、一人一人のこうした小さな不満は、蓄積されると無視できないくらいの量になる。
人々の苦情は多くの人を悩ませる10～20の問題に収斂していくものである。だから、「ユーザー一人一人にとって
不満点は異なる」という、Appleが順位付けをサボったままにしている口実を与えるようなレベルの問題ではないのだ。

バグの順位付けといえば、AppleはメジャーリリースごとにFinderに新機能を盛り込むことに忙殺されている
ために、こうした小さなことは割れ目の中に落ち込んでいくごとく無視しているようである。その分、Finder
自体はリリースを経ても変わっておらず（Mac OS Xの新機能の統合が実際に注目されたことは除く）、
こうした小さなことは修正されないままである。いいですか、4年間経っているんですよ。

14:5/10
05/05/17 16:44:32 X7fjDALu
Mac OS XのFinderに当初込められていた善意も、NeXTスタイルのカラムビュー及び他のブラウザスタイルの
機能の追加により、ここ数年でなくなってしまったようである。ブラウザファンにとっては蜜月時代は終わった
ようである。ブラウザ関連の機能追加の要望も無視されていることに、彼らはだんだん気付いてきている。

Finderのブラウザ方式でない機能が純粋なファイルブラウズ機能と干渉していることに関する不満も、私は
多く見てきた（「デフォルトですべてのブラウザウインドウをリストビューにできないのはなぜ？」など）。
Finderにおける、ブラウザと空間概念の破壊的混在をめぐる過去の騒動すべてが、突然説得力を持ち始めたのだ。

ブラウザファンにとってもっとキツいのは、Path Finderのようなアプリの存在だ。Path Finderは、一人の
デベロッパが開発した、Mac OS XのFinderに様々な機能を付加したブラウザスタイルのファイルマネージャー
である。Path Finderのバージョン1.0はわずか6ヶ月間の開発期間を経て2001年に公開された。現在の
バージョン3はそれよりずっと進化しており、来たるバージョン4ではFinal Cut Proのようなファイル管理方式を
採用している。これはファイルブラウジング方式の革命である。

Tigerが搭載するMac OS XのFinderはこれとはかけ離れたものである。残念なことだ。

Spotlightについて

SpotlightはMac OS Xのファイル管理における偉大なる光明である。2004年のAppleのWWDCでは、
Spotlightは実際にFinderを置き換える可能性があると、Steve Jobs自身が言及した。「Finderを
使わなくなる者が多く出るだろう。ここ(Spotlight)に行けば、何でも見つけることができるのだから」

Spotlightの高速でパワフル、かつ正確なシステムレベルでの検索機能を、私は軽視するつもりはない。
本当に素晴らしい機能で、Finderには全く不向きな仕事をこなすことができる。だが本質は本質である。
Spotlightは検索機能でしかないのだ。

15:6/10
05/05/17 16:45:50 X7fjDALu
ファイル管理機能のすべてを検索機能に負わせるのは自傷行為である。草むらの中に落ちた針を探し出す
には検索機能は便利だろうが、よく利用する少数のファイルを扱う場合は無意味に非効率的である。
フォルダの存在はそのためにある。一見関係のないファイルを一箇所に集めるもの、それがフォルダなのだ。

ユーザー個人の判断でメタデータを付加できるようにしたTigerの新機能をAppleがもっとよく活用して
いれば、Spotlightのスマートフォルダは役に立ったであろう。だが現状では、昔ながらのただのフォルダ
でしかないのだ。

よく利用する「アクティブなセット」があれば、開いているフォルダウインドウ（たとえば、いくつかの
サブフォルダウインドウが開いているリストビューにおいて）にすべてを放り込み、ダブルクリックまたは
ドラッグ＆ドロップしてファイルを開いたり編集しりするのは極めて効率の良い方法である。この直感的な
Finderのインタラクションを検索ベースの代替手段で代替しようとした場合、Spotlightの検索メニューを
有効にしてファイル名の最初の数文字をタイプし、メニューに表示された検索結果から選択（メニューに
出ない場合はフルスクリーンの検索結果画面から選択）し、それを開いたり編集したりするには選択／
ダブルクリック／ファイルをドラッグすればよい。

これは勿論、ファイルのメタデータが検索結果のリストの中から容易に識別できるようになっている、と
システムが推測しているのである。ところが哀れなるWebデベロッパは、Spotlightを同じような名前と
構造を持つ、たとえば"index.html"という一連のファイルを編集するのに用いようとしている。

この場合、ファイルを開くたびにプロセス全体を最初から最後まで行わなければならない。そしてQuicksilver
のような特別なランチャーユーティリティとは異なり、Spotlightはユーザーの取るアクションに基づいて
学習したりはしない。実際、最後に用いた検索語などの状態を保持してくれない。検索は毎回ゼロからの
スタートになってしまうのだ。

（そろそろ連投警告が出るので、続きは後ほど）

16:7/10
05/05/17 16:47:40 X7fjDALu
それでもまだ、ユーザー個人の「アクティブなセット」ではこれが上手くいくように思えるなら、以下のことを
一ヶ月間続けてどう感じるか試してもらいたい。Finderは一切用いない。すべてをSpotlightでまかなうのだ。
さあどうなる？きっとあなたの「アクティブなセット」はハードディスク内のあちこちにデタラメに分散して
しまっていることだろう。もしそうだとしたら、Spotlightは棚ぼたみたいなものだ。

だがあなたが平均的ユーザーなら、今日既に5回開いたファイルを繰り返し検索していくうち（ファイルは
おそらくあちこちのフォルダ内に分散している）、きっと頭がヘンになることだろう。あなたがしばしば
同じファイル名をつけたり、階層化が製品に含まれているような環境で仕事をしているデベロッパだったり
すれば、余計にそうだろう。

ここでも私は、検索の力を軽視するつもりはない。検索機能は偉大であり、検索機能は重要である。
ハードディスクのどこかにファイルがあることだけ憶えているが名前をはっきりと憶えていないファイルを
探すような場合、あるいはどこかで見た単語やフレーズを検索する場合には、Spotlightはうってつけだ。
だがFinderの代替機能はそうではないのだ。

Mac OS Xでは、検索機能の多用は自己達成的予言の一種である。Finderがダメであればあるほど、対照的に
Spotlightが良く思える。しかしながら、どんなにFinderが改悪されようとも、保ち続けている機能が一つある。
それがデスクトップだ。Finderの中で最も空間的に一貫性のあるものとして、デスクトップは事実上すべての
ユーザーが心地良く感じる、コンピュータ上の一つの「場所」である。だからこそ、多くのユーザーが
最も重要な／よく利用するファイルの保存場所としてデスクトップを活用しているのである。

検索機能と、伝統的な構造的情報管理方法との適切な融合の力については、iTunesやMail.appのような
アプリが既に実証してくれている。iTunesの検索機能は素晴らしいが、ジャンル／アーティスト／アルバム
の管理画面がなかったら、もっとずっとストレスのたまるソフトになっていただろう。同じことがMail.appの
伝統的なメールフォルダと検索フィールドについても言える。

17:名称未設定
05/05/17 16:47:51 +ueQ+zE1
GO AHEAD, PLS!

18:8/10
05/05/17 16:48:32 X7fjDALu
どちらの場合においても、階層は詰め込んだ検索結果の組み合わせである。ファイルパスがファイルの識別の
唯一の手段となっている、HFS+のようなボリュームフォーマットについても同じだ。昔ながらのフォルダも
ファイルパスのメタデータに基づく「詰め込んだ検索結果」でしかないのだ。結果的にはメカニズムではなく
インターフェースが重要だ、ということになる。

私はFinderとSpotlightがいつかその可能性に応えられる日が来ることを心待ちにしている。それまでは、
Spotlightの機能をFinderの欠点を補う手段として強調しすぎるのは間違いである。確かにSpotlightは
素晴らしいものだが、だからと言って伝統的なファイル管理方法を捨てていいということにはならない。
Finderはまだお役御免ではないのだ。

内部の変更

TigerのFinderは、内部構造にいくつか変更を受けており、それに触れておくべきだろう。最初に、
Finderの「コピーエンジン」の変更。ファイルの移動やコピーを行うアプリはFinder以外にも存在する。
特にMac固有のメタデータ／リソースフォーク／シンボリックリンク／ハードリンク／サポート対象外の
ボリューム形式に基づくこれらのエミュレーションに関する複雑なルールを有するMac OS Xにおいては、
これはびっくりするほど複雑なタスクである。

旧Mac OSでAppleが取ったソリューションは、単にFinderがそれらのアプリに代わってファイルの
移動／コピーを行うというものであった。これは有効であったが、すべてのアプリケーションがFinder依存に
なるという問題もあった。これは旧Mac OSのアプリがファイル管理において歴史的にFinderに依存していた
ことによる部分もある。Mac OS Xでは異なる方法を取らなければならなかった。Finderは常に動いていて
使うことができるとアプリが推測することは、もはやできなくなった。Mac OS Xのアプリがファイルの
移動／コピーを行いたいのであれば、そのアプリ自身がやらなければならないのだ。

19:9/10
05/05/17 16:49:11 X7fjDALu
Tigerでは、Finderのコピーエンジンをどんなアプリケーションでも利用することのできる共有ライブラリの
中に入れた。TigerのFinder自身もこのライブラリを利用するのだ。特に数年後のファイル・メタデータの
増殖の可能性を見据えた場合、一つのライブラリに「正しい」ファイル操作を統合したことは重要な一歩である。

目に見えるもう一つのFinderの変更点は、Pantherで導入された、ファイルシステムを通知するAPI
（当時のFinderでは活用されていなかったが）とSpotlightの一部として導入された機能との組み合わせから
生まれたものだ。TigerのFinderは、ファイルが作成されたときに正しく表示し、削除されたときに正しく
消えるようになったのだ。

これが大したことでないように思えるのであれば、きっとMac OS XのFinderを十分に使っていない人であろう。
あるいはファイルマネージャーに対する期待度が低い人なのかもしれない。（ウインドウズユーザーかな？F5！）
だが、ファイルマネージャーはディスク上のファイルの状態をタイムリーに反映すべきであるという古風な概念に
我々ジジイがどんなにクレイジーに固執してきたか、読者諸氏はお分かりであろう。

Mac OS XのFinderは、この点においては歴史的にぶざまに失敗してきた。ユーザーが暗黙のうちにウインドウを
クリックするまで、Finder以外で作成されたファイルの表示が大抵できなかったのだ。理論的には、アプリは
Finderに対し、ファイルを作成したらFinderに通知することになっているのだ。実際には、Mac OS Xに関する
高いレベルのAPIの知識を持たないUnixのコマンドラインツールのごとく、多くのアプリがそれをやらなかったし
できなかった。いわんやFinderをや、である。

そんな時代は終わったのだ。カーネルのフックがSpotlight機能をこんなにもレスポンシブにしてくれたおかげで、
TigerのFinderはもう生き残れないのだ。ソースを問わず、Spotlightはファイルシステムの変更を瞬時に反映する。
注目！

（ターミナルでのファイル作成／削除が即座にFinder上で反映されている様子を示すムービー）

20:10/10
05/05/17 16:50:05 X7fjDALu
私は、この変更だけでも、Tigerにおける改悪を（その改良以上に）補って余りあるものだと強く信じている。
もし今Mac OS Xのカーネルデベロッパが私の方に向かって歩いてきたとしたら、強く抱きしめていることだろう。

Finderのまとめ

Mac OS XのFinderの停滞と、過去にこの話題で消耗しきったことから、Finderの泥沼を放置してきたと先に
書いたのは知っている。これまで読者諸氏がお読みになったのはその短縮版だ。しかし、この話題がなぜ
完全に消え去らないのか説明したかったのだ。Mac OS XのFinderに対する不満は実際のものであり、それは
すぐに消え去るという気配もない。

先に私はスマートフォルダの実装方法にやや不満ありということ、及びSpotlightの妙な統合について述べたが、
あえて繰り返す。長らく無視されてきたFinderとの関わりは、結局のところどんなに良く言っても凡庸の山に
見えるということだ。

私はFinderを完全には放棄していない。Mac OS Xのメタデータをめぐる武勇伝が仮に何か私に教えてくれたとすれば、
せいぜいちょっとしたやり方で警戒心がもたらす可能性のことだろうか（訳註：この部分よく分からず）
Appleが重い腰を上げて優先順位のリストにようやく着手するまで、あと何年待てばいいのだろうか。

しかしながら、これらにもかかわらず、TigerのFinderはPantherのそれよりはマシになっている。
ファイルシステムの新たな変更だけでも、アップグレードの価格に値する。以前がどうだったか考えずに、
まあ試していただきたい。

（以上です。あー疲れた）

21:名称未設定
05/05/17 16:52:20 pUis8KrQ
乙！これからゆっくり読ましてもらいます。

22:名称未設定
05/05/17 16:52:29 +ueQ+zE1
YOU DID IT!

23:名称未設定
05/05/17 17:02:14 vYkGlQ+w
乙なのだが、前スレをこのまま放置するの？とかすかな疑問（w

24:名称未設定
05/05/17 17:08:27 UWlrvTEe
乙っす

25:haiyo
05/05/17 17:51:09 /4wXkHIh
きのうの続き！
------------------------------------------------------------
■UTI
UTIを理解するための最初の一歩は、UTIが、Appleの言葉を借りれば「何らかの
『タイプ（型）』を持つと考えられるさまざまなエンティティ（存在）のクラス
（種類・分類）を、ユニークに識別する」ものだということだ。これはほとんど
我々の想像力の限界に迫るほど茫漠とした書き方だが、普通の英語として読むならば、
これはUTIは単なる「ファイル形式」に留まらず、もっと広汎な対象を記述しうる
ものだということを意味している。UTIはファイルだけでなく、データ（たとえば
ペーストボード内のデータやストリーム・データ）、構造化されたファイル／フォルダ
群（たとえばMac OS Xのバンドル）、シンボリックリンク、ハードリンク、果ては
ディスクボリューム全体も記述できる。まさにAppleが言う通り、システム上に
おいて何らかの型に属するような実体は、すべてUTIの記述対象となるのだ。

26:haiyo
05/05/17 17:51:50 /4wXkHIh
UTIは拡張子やタイプ/クリエータコード、MIMEタイプなどが抱えているすべての
問題点を解決するために登場した。

●ユニークさ：全く新しいデータ分類機構であるUTIは、過去の過ちに拘束される
ことはない。個別のUTIはユニークであるように定義され、そのユニークさが
持続的に維持されるよう保障するシステムも備えている。

●表現力と可読性の高さ：UTIには文字列長の制限はなく、人間が読むことを想定
した平文記述も付随している（この記述は多言語ローカライズも可能である）。

●拡張性の高さ：UTIでは、管理団体（この場合はApple）の承認作業を受けると
受けないとに関わらず、新たなタイプを容易かつ安全に追加できる、十全に定義された
体系をサポートしている。

●分類上の正確さ：何らかのデータタイプ（たとえば「全ての画像」）を選択すれば、
ベンダ依存のUTIや臨時のUTIなども漏らさずに、そのデータタイプに属する対象
すべてをちゃんと捕捉できる。

うむむむ、新規格のあけぼの時に漂うほのかな野望の香り、俺は嫌いじゃない。
匂うな…こいつには「階層性」の匂いがプンプンするぜッ！！

UTIは、各ノードがその親ノードに「従属する」形で結びつけられた、木構造的な構造を
持っている。すべてのJPEG画像ファイルは画像ファイルに属し、すべての画像ファイルは
データファイルに属する、といった具合だ。MIMEでもすべての画像に「image/～」
接頭辞をつけることでこうした従属性を実現しようとしていたが、上でも述べたとおり、
この方式はベンダ依存のファイル形式が混じってくると極めて具合が悪いことになるうえ、
最上位タイプの数や範囲も充分な表現力を備えていなかった。

27:haiyo
05/05/17 17:52:59 /4wXkHIh
筆者の観点から言うと、UTIの根本的ブレークスルーは---もしお望みなら「愚にも
つかない発想」と言い換えてもいいが---個別のUTIの表現上の階層構造を、さまざまな
UTI同士の実態的な階層構造から切り離したという点にある。これが基本中の基本だ。

UTI名は、数字・文字・ハイフン・ピリオド、さらにASCII範囲以上のあらゆるUnicode
文字を含むことのできる文字列だ。標準的な型は「public.」接頭辞を持つ。これは
「public識別子」とも呼ばれ、Appleのみが定義できる。Apple以外が作るUTIは全て、
逆順DNS命名規則（たとえばcom.adobe.pdf）を使わなければならない（わお）。

各UTIは他のUTIを「継承」あるいは「従属」できる。下はUTIの階層構造のサンプルだ。

URLﾘﾝｸ(media.arstechnica.com)

HTMLファイル（public.html）とプレーンテキストファイル（public.plain-text）が、
いずれもテキストファイル（public.text）の1種類となっているのがわかる。さらに、
すべてのテキストファイルはデータファイル（public.data）であり、云々と続くわけだ。
ここで再び強調したいのは、UTI名は実際の階層的木構造には全く無関係だということだ。
com.mycorp.myspecialtextというUTIはテキストファイルの1種類になっているが、
UTI名自体はpublic.plain-textを含んではいないし、そもそも「public.」で始まって
すらいない。

もうひとつ覚えておいてほしいのは、public.dataは、UTI木構造の最上位とか、唯一の
ルート階層とかでは全くないということだ。他のUTIを継承しないUTIは、事実上すべて
ルートだとみなすことができるのだ。

28:haiyo
05/05/17 17:54:21 /4wXkHIh
UTIは複数の親UTIを多重継承することもできる。アプリケーション・パッケージ
（Mac OS X上ではひとつのアプリケーション・アイコンのように表示される、特殊な
構造を持つフォルダ）の場合などがそれにあたる。アプリケーション・パッケージは
「バンドル」であると同時に「パッケージ」でもある。

URLﾘﾝｸ(media.arstechnica.com)

アプリケーションは、アプリケーション・バンドル内にあるInfo.plist（XMLプロパティ
リスト）ファイルでUTIを宣言する。この宣言には「エクスポート（exported）」と
「インポート（imported）」の2種類がある。

エクスポートUTIはそのUTIをシステム全体で利用できるようにするものだ。独自の
ファイル形式を持つアプリケーションは、そのファイル形式を記述するエクスポート
UTI宣言を行わなければならない。

一方インポートUTIは、そのアプリケーション自身が「所有」してはいないものの、
アプリケーションが自身の役割を果たすためにシステムに明示しておく必要のある
UTIを宣言する。たとえば、Adobe Photoshopファイルを後処理するための
アプリケーションを考えてみるといい。こうしたアプリケーションはPhotoshopが
システムにインストールされていない場合でも役割を果たせてしかるべきなわけだ。

Mac OS Xがこのアプリケーションに対するドラッグ＆ドロップ操作を適切に処理する
には、ドラッグされているファイルはAdobe Photoshopファイルだということを
Mac OS Xが知っていなければならない。だがPhotoshopがインストールされていない
（すなわち、Photoshopファイル形式を定義するエクスポートUTI「com.adobe.
photoshop」が宣言されていない）場合には、それがPhotoshopファイルだという
ことをOS Xはどうやって知ればいいのだろう？　この問題を解決するために、件の
後処理アプリケーションは「com.adobe.photoshop」に関するインポートUTI宣言を
行っておく。こうすることで、Photoshopがインストールされていないシステム上
でも、PhotoshopファイルUTIの存在と特性をあらかじめ「事前宣言」することが
できるのだ。

29:haiyo
05/05/17 17:55:54 /4wXkHIh
エクスポートUTIとインポートUTIの宣言が矛盾した場合は、エクスポートされた
宣言内容が優先される。エクスポートUTIの宣言はそのUTIを「所有」する
アプリケーション自身が行うわけだから、これは理にかなった仕様だろう。ひとたび
そのアプリケーションがインストールされれば、インポートUTIはもう必要が
なくなるからだ。

UTI宣言には以下の情報が含まれる。

・UTI文字列自身
・そのUTIが継承する親UTIのリスト
・そのUTIと等価な意味を持つ、UTI以外のタイプ識別子（拡張子やMIMEタイプなど）
・そのUTIタイプに属するファイルに使われるアイコンファイルが、アプリケーション・
バンドル内のどの位置にあるかを示すパス
・人間向けに書かれた説明（ローカライズ可能）
・そのUTIを記述するドキュメントがあるURL

「等価な」ファイルタイプのリストは、複数のタイプ識別子を変換するAPIで使われる。
ご想像の通り、ある拡張子や旧Mac OSのタイプコードを変換する際、変換先UTIの
候補がひとつに絞り切れない可能性は充分ありうる。変換APIはその中から1つを選択
するための「ヒント」も受け付ける（たとえば、フォルダやその他のエンティティでは
なくファイルから拡張子情報を受け取った場合は、public.dataの下位タイプだけを
考慮すればよい）。ヒントが一切与えられない場合、APIはpublic識別子を優先する。

あるエンティティを示すのに適切なUTIがない場合は、動的に生成されたUTIが使われる。
この動的生成UTIは「dyn.」接頭辞から始まり、たとえ一時的にしか意味を持たない
エンティティであっても、システム内で一切重複が発生しないように生成される。

デベロッパは、新規UTIが継承するプロプライエタリUTIが既に自社アプリケーション
上で宣言されている（あるいは自社の別アプリで宣言されている）場合を除き、極力
public識別子を継承するよう推奨されている。

30:訳した人
05/05/17 17:57:49 X7fjDALu
訂正2箇所。

>>13
ウインドウはウインドウ内の項目をできる限り多く表示し、かつ余分なスペースをなくした状態にリサイズ
されるはずである。
（はず「で」ある：「で」の追加）

>>15の3段落目
よく利用する「アクティブなセット」があれば、開いているフォルダウインドウ（たとえば、いくつかの
サブフォルダウインドウが開いているリストビューにおいて）にすべてを放り込み、ダブルクリックまたは
ドラッグ＆ドロップしてファイルを開いたり編集したりするのは極めて効率の良い方法である。
（編集し「た」り：：「た」の追加）

>>23
なんとか残しておきたいけど、ルクダルさんが過去ログのHTMLやめちゃいましたからねえ。
1000逝ってしばらくすればにくちゃんねるで読めるようになりますけど。
埋め立てた上でどなたかログをうｐしていただけると助かるんですが。

31:haiyo
05/05/17 17:57:53 /4wXkHIh
Appleは膨大なエンティティをカバーする、100近くにも及ぶ定義済みUTIリストを
用意している。以下はそのごく一部だ。

（URLﾘﾝｸ(arstechnica.com) 中段のテーブルを参照）

見ての通り、何人たりともUTIの襲撃からは逃れることはできない。またAppleは
Adobe PDFやMicrosoft Word / Excelなどの一般的ファイル形式のインポートUTI
宣言も行っている。

UTI宣言で他のタイプ識別機構を記述する際にもUTIが利用されているのは、まさしく
UTIの絶対的支配の象徴とも言えそうだ。

（URLﾘﾝｸ(arstechnica.com) 中段のテーブルを参照）

■ファイル分類のまとめ
話は簡単だ。データの種類をユニークに同定・識別することにかけては、MIMEも
タイプ/クリエータコードも拡張子も等しくクソで、UTIは神だ。MIMEタイプや
タイプ/クリエータコードは（特に保存領域に関しては）拡張子よりはマシな
システムかもしれないが、拡張子の抱えていた問題の多くが解決されていない。
上の表を見て、同じものを表すのに使われているMIMEタイプやタイプ/クリエータ
コードがいくつあるか数えてみればいい。'MPG '、 'MPEG'、video/mpg、video/mpeg、
video/x-mpg、video/x-mpeg…。ユニーク性の問題に頭を悩ませてきたのは
拡張子システムだけではないのだ。

UTIは過去のしがらみを捨て去り、俎上にさまざまな新たな可能性をもたらした。
UTIに今後大きな改善が期待される点があるとすれば、それはAppleが完全管理し、
Mac OS Xだけで使われるシステムから、オープンな標準へと成長することぐらい
だが、現実にはこれはケーキをきれいに飾りつけるかどうかという程度のささいな
話でしかない。他のデータ分類機構のとる値をUTIにマッピングできる以上、他の
OSがどの分類機構を使っているかはさほど重要な問題ではないのだ。他のOSが
追従するのを待望する向きもあるだろうが、ともあれMac OS X Tigerは現時点でも、
先行技術をはるかに上回る、強力で拡張可能なデータ分類機構を擁しているのだ。

32:名称未設定
05/05/17 17:59:38 /4wXkHIh
もちろん、いくら優れた標準技術でも、実際に使われなければ意味はない。筆者は、
今後MacOSのAPI群は徐々にUTIをデータ識別手段として利用する方向に改良されて
ゆくと予想する。筆者が「Spotlightでは、個別のファイル形式に応じて、それぞれ
別のメタデータ・インポータ・プラグインを利用している」と書いた（訳注：第9節
へリンク）のを覚えているだろうか？　ここでSpotlightが個別のファイルを特定の
メタデータ・インポータ・プラグインに対応させるのに利用している「ファイル
形式」は、実はUTIなのだ。Spotlightが各ファイルのUTIに対して（場合によっては
複数の）対応可能なインポータを照合して「一番ふさわしい」メタデータ・
インポータを選択する際には、UTIの持つ階層性が威力を発揮しているのである。

Tigerには、すでに旧式のデータタイプとUTIを相互変換するAPI群が含まれている。
デベロッパは、ファイルタイプの移行に関する社内方針を決定すれば、いつでも
UTIのみの利用に切り替えられるようになっているのだ。そしてAppleもこの移行を
支援しているように見受けられる。

残念ながら、UTIはアプリケーションの内部のみに存在する概念である。Appleは、
ファイルタイプを外部に明示するための推奨手法を拡張子からUTIへ切り替えると
いう、次の一歩は選ばなかった。拡張子は考えられうる最悪のファイル分類機構では
あるが、最も広く使われているのもまた確かだ。筆者はOS Xで拡張子の使用を
サポートしたAppleの方針に反対したことはない（し、事実上支持してもきた）。
Appleが犯したとんでもない過ちは、拡張子を「標準の」ファイル分類機構として
承認したことなのだ。

だがUTIによって、Appleはうまいことこの決定を道半ば程度まで翻すことができた。
内部的に（アプリケーションとOS自身から）見れば、UTIはもはやファイル分類だけ
でなく、あらゆる「分類」作業において推奨される標準規格となっている。

33:haiyo
05/05/17 18:01:08 /4wXkHIh
だがAppleのインターフェイス・ガイドラインによれば、外部的には、拡張子は
依然として「準拠すべきファイル分類機構」ということになっている。拡張属性の
サポートによって、Tigerでは既にすべてのファイルに「公式の」ファイルタイプ
識別子としてUTIを格納することができるようになっているのだから、これは
何とも情けない話だ。Appleは単純に、それを推奨しないという道を選んだ。

（興味深いことにTigerでは、タイプ/クリエータコードは既に（冗長にも？）
この方法で格納されている。ファイルにタイプ/クリエータコードを割り当てると、
新たに「com.apple.FinderInfo」という拡張属性キーが作られ、タイプ/
クリエータコードを連結した値が格納されるのだ。ファイルにタイプ/クリエータ
コードを割り当てる際には常に、この処理が透過的に行われる）。

変換APIの追加によって、UTIを正式に「Mac OS Xで推奨される外部ファイル
分類機構」とする準備は既に整っている。つまり、拡張子を「利用可能だが、
デフォルトではない」仕様として徐々に撤退を迫ることもできる状況なのだ。
そうなればいよいよ、ユーザーは本当の意味で完全に任意のファイル名をつける
ことができるようになる。というか、そもそも最初からそうあるべきだったんだが。

今のところ、こうした構想は全て夢（少なくとも、筆者にとっては夢だ）のまま
だが、Tigerの将来にそうした動きを期待するのは悪くない。このツケは長いこと
未払いのままだったのだ。Tigerでなされた改善はよくできている。筆者が期待を
全て満たすものではないにしろ、予想よりは優れていた。あとはこの傾向が
続くことを祈るのみだ。

34:haiyo
05/05/17 18:04:39 /4wXkHIh
おわたよ！

35:30
05/05/17 18:05:57 X7fjDALu
haiyoさん乙です。
翻訳載せ始めたのを知らず割り込んでしまいすみませんでした。

36:名称未設定
05/05/17 18:18:38 /4wXkHIh
>>35
デージョーブです、おつかれさまでした。

37:名称未設定
05/05/17 18:53:15 28flIGlx
仕事中なのに読みふけってしまったｗ
めっさわくわくする記述が多いね。翻訳乙です！

38:haiyo
05/05/17 19:18:54 /4wXkHIh
>>30さん
最後のまとめの（訳註：この部分よく分からず）のところですが、以下のような感じに
読みました。

私はFinderに完全に見切りをつけたわけではない。Mac OS Xのメタデータをめぐる長編
物語から私が何かを学んだとするなら、それは、少なくとも★vigilanceを怠らなければ、
たとえささいな内容ではあれ、いつか何らかの形で報いが得られる望みもなくはない、
ということだろう。私はただ、Mac OS XのFinderがAppleの改善優先順位リストの
上位に登ってくるまでに、あと何年待たなければならないのだろうかと考えているだけだ。

★vigilanceは字義的には警戒・用心ですが、正規の法執行によらない、一般人による
自警団的行動のことも指すようです。Siracusaが以前にやってたメタデータ絡みの嘆願
活動なんかを指しているんじゃないでしょうか。

39:DayTripper ◆BH24DAYTRI
05/05/17 20:10:09 /tm+pKjI
翻訳者さん達、いつもいつもGJでございますよ。

>>30
よかったらうちで過去ログ預かろうかと思いますが。
初代スレ以外ならdatもあるからHTML化もこっちでできます。

40:名称未設定
05/05/17 21:10:31 kBWzGIEn
お二方、おつかれさまでした。
ファインダは私はクラシック形式で使ってるなあ。エクスポゼ登場まではブラウザ形式にしてましたが、
エクスポゼでたくさんウインドウを開いても大丈夫になったので。

UTIはかなり興味あります。これはいい、かなりいい。すでにCocoaなどのメソッドとしても導入されて
いるのだろうか。ちょっと調べてみよう....

41:名称未設定
05/05/17 21:18:52 tdxhjvXI
皆さん乙です。

Tigerで初めてファイルのコピーエンジン？を共有ライブラリに入れたというのは初耳でした。
こうやって読んでみるとさも当然のように思えるけれども、ようやくFinderから分離したというのが意外な気がします。
その意味では、Finderが初めてワン・オブ・ゼムな存在になったのがTigerと言えるのかもしれませんね。
実はこれ読んでPath Finder 4が楽しみだったりｗ
Panther以降ほとんど使わなくなったアプリですが、↓これを見る限り、
URLﾘﾝｸ(www.cocoatech.com)
結構期待してもいいかも。

42:名称未設定
05/05/18 02:40:33 ERY1y597
今回の翻訳を読んでから、この記事

URLﾘﾝｸ(pcweb.mycom.co.jp)

に書かれているmdlsコマンドでいろいろなファイルやらディレクトリのメタデータを表示してみました。
いや思ったよりたくさんのメタデータが登録されてるんですね。

sudo mdls /Applications/Calculator.app

ってしただけで結構表示されました。やっぱり日本語アプリ名称がちゃんとメタデータに含まれてました。

43:42
05/05/18 02:42:12 ERY1y597
すみません、途中でなげちゃった。
なにが言いたかったかと言うと、今回の翻訳に上がってた、UTIがいっぱい登録されていますね。
計算機単体で、８個の階層構造になっているみたいです。この技術、かなり将来性が高そう...

44:名称未設定
05/05/18 06:55:44 D3/Juhu7
前スレ埋まったね。ということで>>39さん、HTML化よろしくおながいします。

45:DayTripper ◆BH24DAYTRI
05/05/18 14:47:31 x1yoMLEZ
>>44
うい、帰宅したらHTML化したものをうｐっときます。

46:DayTripper ◆BH24DAYTRI
05/05/19 01:14:28 PGnn6jhP
遅くなりましたが、過去ログ収集完了。
下記が一覧ページになります。

URLﾘﾝｸ(homepage.mac.com)

# .mac容量やべぇ……。

47:haiyo
05/05/19 01:21:16 qChsyyAN
>>46
乙です～。さっき初代スレのログ読み返してて思い出したけれども、
DayTripperさんって初代スレの頃からこのスレにいてくれたんだねー。
なつかしー。

48:名称未設定
05/05/19 05:05:27 seqfnqDU
訳者さまたち、おつかれさま。
読み応えある内容だったので読むきるのもちょっとひと苦労でした…。

Finder はもう、いったいなんなんでしょうね…。
どうにかならないんでしょうか。

さて、宇津救命丸の１１節。
UTI とはこれ、Apple らしいエレガントなシステムですねぇ！これは素敵。
OpenDoc に始まり、Apple はファイル形式と敢然と立ち向かってきたけれど…あ
…うぅ～、やな事を思い出してしまった、OpenDoc …。
結局「アプリケーションとファイル」、ていう関係は崩せなかったか。
でもこの関係が既存のシステム（や人間）にとって最も受け入れやすいものなのかな。
ただ、仕組みとしては素晴らしいけれど果たしてどれほどの可能性を見いだせるか。
当面、Spotlight みたいな機能を活かしていくためには必要だけれど
OpenDoc の二の舞にならないためには Apple が旗を振ってがんばらないといけないでしょうね。
サードパーティーにとっても大きな魅力のあるシステムとなるはずですからがんばってほしい。

49:名称未設定
05/05/20 22:56:02 gfKDT1o0
Apple Human Interface Guidelines (Tiger)
の翻訳ってされた？

50:名称未設定
05/05/20 23:48:03 FBpiLPSA
>>49
HIGって凄い分量じゃないの？

51:haiyo
05/05/21 00:05:04 jfctcFeI
最新HIGはこちらです。ちょっと1人では無理かも。
URLﾘﾝｸ(developer.apple.com)

もしみんなでやるにしても、このスレではなくWikiとかを使って
プロジェクト的に進めた方がいいでしょうね。画像もいっぱい
入ってくるし。

52:DayTripper ◆BH24DAYTRI
05/05/21 00:09:07 0MZAXQYb
無理かもっつーか、無謀だと思うが (笑)

正直、それはアポーの仕事であって、いまだに翻訳されないのは怠慢だよなぁと思う。
もし2chでプロジェクト建ててやるなら、それこそアポーから金もらえてもいいぐらい。

53:haiyo
05/05/21 00:33:29 jfctcFeI
Appleに言っても金出すどころかイチャモンつけられそうですからね…。

54:名称未設定
05/05/21 00:42:36 ibbnnza/
IBM は文書を日本語化してるのに…

55:名称未設定
05/05/21 00:55:45 UhAGlGCh
完成したあと「買い取りませんか」と打診する

56:名称未設定
05/05/21 00:58:27 mHoXGH6Z
>>55
で２ちゃんねらーに拒否されて"OK, we'll bury you."と冷たく言い放つ。

57:名称未設定
05/05/21 02:00:23 FCSC4CAC
以前もdev文書を翻訳して公開しようと盛り上がった事があったけど、結局Appleから
許可が下りずに立ち消えになった事があったはず。
そのくせ、自前では翻訳文書をいつまでたっても充実させようとしないから同じ意見が
再燃するんだよねぇ・・・。

58:名称未設定
05/05/21 02:09:21 MkOh1bjT
翻訳文書サイトはいくつもあったけど、Apple Japanからのクレームで閉鎖しまくった。

59:haiyo
05/05/21 02:10:25 jfctcFeI
>>58
そんなこともあったのですか。

60:翻訳、乙でございます
05/05/21 12:06:42 KXlJTZ0A
>>58
正直、アホやなと思った。

翻訳すること自体がクレームの対象なのか？
誤解を受けそうなテクニカルタームだけ、監修させてもらうぐらいの立場で、
協力すればいいものを。

でもApple Japanですよね？　今はいくら何でも違うよね？

61:名称未設定
05/05/21 12:14:17 nJiEdyPm
翻訳した文章を公開するのは、Appleの許可がいるだろ。
協力するという申し出を断ったのは、
外部の（もしくは信頼できない）人間には頼めないということだろう。
それは企業としてわからんでもない。
でも断るくらいなら自前でちゃんとやってくれよってこった。

62:名称未設定
05/05/21 12:15:19 xDyB1kak
非公式な翻訳にクレームがついたことあったっけ？
公式に許可取ろうとして駄目だったケースなら知ってるけど

63:名称未設定
05/05/21 12:18:23 zaYuqmCR
一応建前論から言うと、著作権法に抵触する恐れがあるからでしょ。
ただそれを杓子定規に取るのはケツの穴が小さいと思うけど。

64:名称未設定
05/05/21 12:45:32 LK8U5qoc
去年唐突に、結構な分量のObjective-Cのガイダンスが翻訳されたりしたし、
完全に放置するつもりでもないんだな、と信じたいんだが、いかんせんやる気が
見えないのがイライラするね。

65:名称未設定
05/05/21 12:56:56 ibbnnza/
クレームなんてあったのかソースは？
いちいちそんなことやるほど人的リソースはないんじゃない？
Safari の日本語化も 2ch でやってけどなんか言われたっけ？

66:名称未設定
05/05/21 13:15:47 ibbnnza/
bitchvalley っていう懐かしい人がアップルのサイト丸パクリで
クレームがくるんじゃないかっていうスレはあったけど、文書の翻訳でクレームってのはぐぐってもなかったな。
少なくとも OS X 以降は聞いたことが無い。

67:名称未設定
05/05/21 13:45:35 LK8U5qoc
Safariの時は、2chで個人的に翻訳してた人のを、Appleが参考にするとかなんとか
コンタクトがあったらしく、それでリリースは一旦止まったんじゃなかったかな。
翻訳の質に関して関連スレでは揉めていたような記憶も。

68:名称未設定
05/05/21 13:59:38 ibbnnza/
>>67
あったね。美容師 vs 2ch だっけ？でもそれは文書じゃないし、>>58の言うように
>翻訳文書サイトはいくつもあったけど、Apple Japanからのクレームで閉鎖しまくった。
ならどこかにそういう形跡は残ってるんだけどな。>>58 のソースが気になる。
今後もし何かやるなら不都合が出てくるだろうし。

69:名称未設定
05/05/21 14:06:43 zaYuqmCR
あと非公開βを無断で公開したページのファイルそのものを直リンした厨房もいたね。
ほんとあの頃はSafariをめぐる厨房な問題が多過ぎてねえ・・・

70:名称未設定
05/05/21 15:23:57 KXlJTZ0A
>>69
リンゴ部屋ね。

ま、それだけMSのIEには、ウンザリしていたってことだな。

71:名称未設定
05/05/21 17:05:24 MkOh1bjT
WebArchive.orgを使うと痕跡あるよ

72:名称未設定
05/05/22 00:16:41 Jl5lOG3M
>>70
>ま、それだけMSのIEには、ウンザリしていたってことだな。

オレはあの直林のおかげで、Mac を買う決心がついた。
林檎部屋は神

73:名称未設定
05/05/22 00:25:04 DN2vXSd5
>>72
釣れますか？

74:偽の神
05/05/22 16:26:21 eTJrenZq
最近は本物の神がおわしますので出る幕がないです。
とりあえず、CoreImage対応GPUに関する、最もわかりやすい資料を翻訳。

URLﾘﾝｸ(developer.apple.com)

Q.
CPUとGPU、どちらがCoreImageに使われるのでしょうか、
また、それをどうやって設定するのでしょうか？

A.
CoreImageはCPUとARBfragmentに対応したGPU、両方を使えます。
特に指定されていない場合、CoreImageは使用するプロセッサを単純なルールにそって選びます。
表1にそのルールを示します。

表1 GPUが、
・GeForce 5200シリーズ = CPU（注記を見てください）
・ARB fragment 対応ハードウェア（GeForce5200シリーズを除く） = GPU
・ARB fragment 未対応ハードウェア = CPU

※ARB fragment = OpenGLのプログラマプルシェーダ機能拡張です。
URLﾘﾝｸ(developer.apple.com)

注記：デフォルトでは、GeForce5200シリーズを搭載したMacではCPUが使われます。
なぜなら、過去に出荷したMacでは、ほとんどのベンチマークでGeForce5200がCPUよりも遅いからです。

75:偽の神
05/05/22 16:27:21 eTJrenZq
数々の理由から、開発者にはCPUとGPUを併用していただきたいと思います。
・GPUを並列動作させて、CPUの負荷を下げます。
　GeForce5200でも、アプリケーションによっては十分に高速でしょう。
・正確な再現性が得られます。CPUはIEEEの精度保証に準拠しており、従ってGPUは演算内容を明確に定義できます。
・64以上の命令を含むfragmentプログラムでは、いくつかのGPUで最大64命令に制限されてしまいます。
　fragmentプログラムは演算にCPUを使わせるようCoreImageに指令を出すことができます。

CoreImageにCPUを使わせる場合、CIContext作成時にkCIContextUseSoftwareRendererフラグを宣言します。
kCIContextUseSoftwareRenderer=YES なら、CoreImageは常にCPUを使ってレンダリングを行います。
もしkCIContextUseSoftwareRenderer=NOなら、（可能であれば）GPUが使われます。

リスト1：常にCPUを使ってレンダリングするCoreImage Contextを作成するコード例

変更履歴
2005-05-12 公開

76:名称未設定
05/05/23 11:04:38 i5FHns4S
空気読まずにMac.arsのTigerレビュー、19ページの「パフォーマンス」の翻訳をば。

パフォーマンス

TigerのパフォーマンスについてはPantherのそれと多くの点で同等なので、ズルをしてPanther
当時書いたことを元に敷衍していこう。

Mac OS Xの登場から4年間。リリースごとにMac OS Xは速くなっていった。それは単に「ほとんどの
エンドユーザーに体感できる高速化」というにとどまらず、同じハードウェア上でも速くなっていたのだ。
これは現代のデスクトップOSでは他に聞いたことがないような進化だ。旧Mac OSではこんなことはなかった。
同じハードでも、OSのリビジョンが新しくなると遅くなっていった（System 7とMac OS 8の比較とかね）。
Windowsの世界でもだいたい同じような傾向があった。OSが新しくなると、ハードも新しくしないと
その真価が発揮できないというのが当然だと考えられてきた。

だがこれはMac OS Xについては当てはまらない。同じハードで動かしていても、Mac OS Xはメジャー
リリースごとに、前のバージョンより速くなっていった。バージョンを一つ二つ飛ばしてアップグレード
すると、まるでハードを新しくしたかのように速くなった。これは印象的で、前代未聞のことである。

勿論、後ろ向きな見方をすれば、Mac OS X 10.0の性能は悲惨の極みで、そこからは性能は下がりようが
なかった、とも言える。System 7とMac OS 8との比較がそうであったように、同じハードにおいては
（構造は全く異なるが）以前のMac OS 9と比較すると、Mac OS Xは明確に遅かったのである。

だがそれもほとんど追いつきつつある。急ごしらえで出したために非常に無駄の多かった10.0のコードに対し、
ある意味において、パッチを当てるよりもはるかに多くのことをAppleはやってきているということを
認めないわけにはいかないだろう。ようやく看板に偽りなし、と言えるようになった。AppleはOS Xの
高速化を続けてきており、それに成功している。

次ページ