Mac関連ﾈﾀをそれはもう凄まじい勢いで翻訳するｽﾚ7

1 ：>>1ｽﾚﾀｲ変えんな死ね：2007/11/03(土) 15:57:38 ID:SzlGvfIS0

[前スレ]
Mac関連ネタをもの凄い勢いで翻訳するスレ 6
http://pc11.2ch.net/test/read.cgi/mac/1140671343/

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

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

［過去スレ］
Mac関連テキストをすごい勢いで翻訳するスレッド
http://pc.2ch.net/mac/kako/1020/10204/1020487234.html
Mac関連ネタを凄い勢いで翻訳スレ2
http://pc.2ch.net/test/read.cgi/mac/1035938842/
Mac関連ネタを凄い勢いで翻訳スレ3冊目
http://pc.2ch.net/test/read.cgi/mac/1051925818/
Mac関連ネタを凄い勢いで翻訳するスレ・４
http://pc7.2ch.net/test/read.cgi/mac/1073284076/
Mac関連ネタを凄い勢いで翻訳するスレ5
http://pc7.2ch.net/test/read.cgi/mac/1116278311/

9 ： ◆FljYzA.syg ：2007/11/05(月) 01:15:26 ID:BoAoHrCW0

Ars technicaの記事続きです。私はここまでということで。

その他内部構造についてのいろいろ
これからの"grab bag"セクションでは、独立したセクションまでは行かない、あ
るいは時間的制約のため一つのセクションにまでまとめられなかった興味深い機能
について簡潔に触れる。最初にその後のマウスを使うような機能と分けるために内
部構造について語る。別の言い方をすれば、スクリーンショットのないセクション
だ。では、始めよう。
まともに使えるメタデータ
LeopardはTigerで追加された拡張属性APIの利点を真に享受した最初のOS Xだ。
あるファイルやディレクトリの情報が必要な問題に面して、Appleはようやく
（うげ！）これを実装するためにファイルシステムのメタデータを利用しようとしている。
これはLeopardのあらゆる場所で見られる。これら拡張属性の名前を見よう

com.apple.metadata:kMDIntemFinderComment
実際のメタデータ中のFinderのコメント。（これらは.DS_Storeファイルにも保存
されている、Leopard以前のシステムとの互換性のためであろう）

com.apple.quarantine
インターネットからダウンロードされたファイルに信頼できない可能性を示すため
のタグをつける。そのようなファイルをダウンロードするアプリケーションのため
に用意されている。

comp.apple.backupd.SnapshotVolumeLastFSEventID
後のセクション(Time Machine)で述べるバックアップ機能で使われる拡張属性の
セットの一つ。

10 ： ◆FljYzA.syg ：2007/11/05(月) 01:16:33 ID:BoAoHrCW0

私は大声で叫びたい。「ハレルヤ！Appleはついにやってくれた！どんなに便利か見
てみろよ！これを保存して追跡するために、メタデータによる啓蒙を受ける前の
Appleがやってきたこと、アプリケーションが別々に実装してきたこと、その気違い
じみたダーティーハックを想像してみろよ。なんという無駄な努力、なんという独
特のバグ。もうたくさんだ！拡張属性は同じことをやるために、一ヶ所でデバグさ
れる一般的な方法を提供したんだ！」

Leopardはコマンドラインユーティリティも含んでいる。これは拡張属性を見たり書
き換えたりできる。これを読んだ人はは私のTigerのレビューで紹介したMarquis
Loganによるxattrというよく似たユーティリティを思い出すかもしれない。Apple
はオプションこそ違うが、全く同じ名前のユーティリティを作った。

Leopardでの他のコマンドもまた拡張属性を理解するようになった。例えばlsコマン
ドはパーミッション文字列の後に「＠」で拡張属性を示す。Leopardシステムをls
とxattrコマンドで探索するとAppleがファイルシステムのメタデータをどれだけ重
要視しているかが分かる。これはここまで。

11 ： ◆FljYzA.syg ：2007/11/05(月) 01:20:44 ID:BoAoHrCW0

Core Text

OS Xはついに単一の、公式の、そして標準のテキスト描画とレイアウト用のAPIを持
つことになった。Core Textだ。（私が知っている限り、この「Core」テクノロジー
は例のキャンディーのような球体アイコンはない）Core TextはTigerとそれ以前に
あったテキスト用APIの混乱する文字のごった煮を置き換える。これらの多くはクラ
シックなMac OS由来のATSUI, MLTE, QuickDraw textを引き継いでいた。

Core TextはきれいなAPIを持ち、より高速だし、64bitで使えるし、それからそれか
ら。私は二つの理由でこれを個々で紹介する。第一にCore TextはプライベートなAPI
としてTigerに存在したからだ。これはApple独自のアプリケーションでフレームワ
ークの試験用に用いられていた。Leopardはこれを公開して、きちんと整えてきた。

これはFSEventsの状況と似ている。しかしFSEventではAppleはプライベートAPIをTiger
でオーディションにかけて、一般での利用には向かないと判断し、Core Textは必要
だとされた。多分Core Textとは違って/dev/fseventsは決して公開されないだろ
う。あるいは目に見えないところにのみいるだろう。どちらにせよ、10.6で公開さ
れるかもしれないLeopardのプライベートなフレームワークに注目しておくといいだ
ろう。

第二の理由はCore TextはOS Xがプラットフォームとしていかに（相対的な意味で）
未熟かということも示している。Leopardは表面上は6番目のリリースで成熟してい
るわけだが、ようやく標準のテキストAPIを持ったというのだ。一見してOS Xが成熟
してみえるというのは、実のところ生まれたときからいろいろなテクノロジーのご
った煮であったのだ。BSD Unixがここに、NeXTがそこに、クラシックなMac OSのバ
ケツを頭からかぶって。これらを整理するのには時間がかかる。Leopardはいくかの
古いテクノロジーを非推奨にして後継テクノロジーを任命することで重要な進歩を
いくらか進めている。

12 ： ◆FljYzA.syg ：2007/11/05(月) 01:21:33 ID:BoAoHrCW0

コードの署名

Leopardは暗号化及び署名付きアプリケーションをサポートしている。このトピック
はある種の人々に対して警戒信号を発する。議論の多いMicrosoftのPalladium (NGSCB)
構想は数年前人々に警戒を引き起こした。これはMicrosoftがマーケットについて
判断を誤り、彼らが対象としていたセキュアなユートピアではなく独占企業による
鉄拳制裁という寒々とした未来をイメージさせるという結果になったからだ。今日
では「セキュリティ」という楽観的な美名で飾られて、勢力争いは警戒より楽観に
傾いた。

Leopardにおける署名プログラムについて理解するために、第一に言うべきことは、
これは上記に上げたようなものでもないし、そうたいしたものでもない。これでApple
（や他の誰か）があなたのシステムを全てコントロールするわけでもないし、破ら
れることのないセキュリティを提供するわけでもない。

じゃあ何をするのか？プログラムの署名はコードが同じであることを確認し、全く
改変されていないことを保証するものだ。その中身については何の保証もしない。
例えばAcme Inc.によって署名されたアプリケーションをダウンロードしたとしよ
う。それでできることといったら最後にウェブからダウンロードしたときのAcme Inc.
にあったものと同一であるということの証明だけだ。

消費者から見てこのテクノロジーの最も有用な例を示そう。今日OS Xのアプリケー
ションをアップグレードするとユーザーはそのたびにユーザー名とパスワードを取
得するためにキーチェーンにアクセスしていいか確認を求められている。これはセ
キュリティの機能としてはいいのだが、実際はMacユーザーに盲目的に「常に許可す
る」をクリックさせるよう訓練しているだけだ。ディスアセンブラを使ってプログ
ラムを走らせたり手作業でコードが安全かどうか確認することが平均的なユーザー
がやることだろうか？

13 ： ◆FljYzA.syg ：2007/11/05(月) 01:22:29 ID:BoAoHrCW0

署名付きアプリケーションは一方で、それが実際に、あなたがかつて信頼したベン
ダーから提供された、新しいバージョンの同じアプリケーションであることを数学
的に証明する。その結果、ユーザーが調べようのない安全性について選択させるよ
うなダイアログの表示を終わらせることができる。

最終的には信頼するかどうかの問題になる。あなたがAcme Inc.のソフトウェアを
信頼するか、あるいはしないか。それはあなたが決めることだ。署名付きアプリケ
ーションだって、署名されていないアプリケーションと同様にあなたのハードディ
スクを消したりパスワードを盗んだりすることができるのだ。

しかし署名なしのコードとは違い、署名付きアプリケーションはインストール後に
変更されることはない。もしAcme Inc.製のアプリケーションが不正なことをした
ら、それはマルウェアによってアプリケーションがハイジャックされたためでない
ことは確かだ。別の言い方をすれば、行儀のいいコードはずっと行儀がいい。
書き換えようとすれば全く動かなくなる。

AppleはLeopardに同梱されている全てのアプリケーションに署名をしている。著名
なサードパーティーの開発者はそのうち同じようにすると思われる。

署名付きアプリケーションは自分を修正するアプリケーションという試みの終わり
でもある（例えば~/Library/Application Support/MyAppやその他のユーザー用
の場所にではなく、アプリケーションの内部にカスタマイズされたテーマファイル
をバンドルするとか）。こういうやり方はAppleによって推奨されてこなかったが、
これでまた避けるための理由が増えた。

14 ： ◆FljYzA.syg ：2007/11/05(月) 01:23:19 ID:BoAoHrCW0

まとめると、コードに対する署名は以下のことを行う。

・確実にコードに封印する
・封印が同一であることを確かめる

一方で以下のことをしない。

・特殊な権限の授与
・バグからの保護
・間違った信頼からの保護
・コピーの禁止
・Matrix世界における奴隷化

これはセキュリティを高める小さな一歩であるが、正しい一歩である。


ASLR

セキュリティのため、Leopardはアドレス空間ランダム化(ASLR)をサポートした。
名は体を表すのだが、ASLRはプログラムをメモリ空間上にランダムに配置し、不正
なプログラムが特定のコードがどこにあるか予測しづらくする。AppleはMicrosoft
がやっているようなセキュリティに関する偏執狂的レベルまでは達していないが、
OS XはWindows並のマルウェアの圧力からは逃れている。よって、やられてから反応
するよりも先にこういったアイデアを取り入れるのはAppleによってよいことだ。

15 ： ◆FljYzA.syg ：2007/11/05(月) 01:24:18 ID:BoAoHrCW0

LLVM

LLVMはlow level virtual machine（低レベル仮想マシン）の略である。これはオー
プンソースプロジェクトだが、Appleはコードの改良のために主要な開発者を雇用し、
育てているプロジェクトでもある。LLVMについてはこのプロジェクトのウェブサイ
トから全ての情報を得ることができるが、そこにある説明はコンパイラ技術に詳し
くなければ理解不能だろう。LLVMが何かを知るための最良の方法はその名前にある。
つまり、バーチャルマシンなのだ。ただし古典的な、PC全体を模したバーチャルマ
シンではなく、非常に低レベルの、CPUのように振る舞うバーチャルマシンだ。

どうしてそんな低レベルなものを真似しなければいけないのだろう。誰が存在しな
いCPUのためにコードを書くというのか？実は、それをやるのはコンパイラだ。この
アイデアは、一度LLVM用のプラットフォーム中立な中間記法(intermediary
representation;IR)で作成するとLLVMはそれを最適化して選択されたCPUの
ネイティブなコードに変換するのだ。この変換は伝統的な実行ファイルを作成する
こともできるし、プラットフォーム中立コードで出荷してLLVMに実行時コンパイル
(just in time;JIT)させることもできる。

どうしてLLVMという仲介業者にやっかいにならないといけないのだろう？ネイティ
ブコードをコンパイルさせてくれないのはなぜ？ほとんどのコンパイラがそうして
るのに。残念ながらコンパイラという奴は、やるにはやるがその品質はばらばらだ。
LLVMの目的は誰もが使えるコンパイラの部品を提供することにある。異なったコン
パイラに拡散した最適化の努力を一つのプロジェクトに集中させるために。だから
プラットフォーム中立なIRを使うのだ。

16 ： ◆FljYzA.syg ：2007/11/05(月) 01:25:02 ID:BoAoHrCW0

これは大きなじょうごのようなものだと考えるといい。想像しうる限りのコードを
上におけば、LLVMのIRとなって落ちてくる。LLVMは文献にある全ての技を使ってそ
れを最適化してする。最終的にLLVMはIRからネイティブコードを作成する。開発努
力の集中は明らかだ。あるたっと一つのフォーマット(LLVM用IR)を扱う唯一の最
適化エンジンとターゲットのCPU用の唯一のネイティブコードジェネレータ。LLVM
が速くなり、賢くなれば、全てのLLVMを使うコンパイラもよりよくなる。

とはいえこれは宣伝文句で、現実にはコンパイラの世界にこの手法のメリットを説
得するのには長い道のりを要する。しかしAppleはこの船に乗っている。Leopardで
はLLVMが使われている。それは変な部分にみえるかもしれないが、OpenGLだ。

ビデオカードがある機能をハードウェアでサポートしない場合（例えば特定のピク
セルシェーダやバーテックスシェーダの命令）、ソフトウェアで処理しなければな
らない。モダンなプログラマブルGPUはある困難を引き起こしている。OpenGLアプリ
ケーションは固定した関数を呼ぶだけではなく、実行時に小さなプログラムをGPU
に引き渡すことができる。

LLVM以前ではAppleはプログラマブルなGPUにApple製のカスタムJITを使うことでこ
れら全てに対してソフトウェア処理を実装していた。Appleはプリミティブな命令そ
れぞれに（例えばドットを打つこと）ネイティブなコードを書いていた。これらは
ランタイムで一つにまとめられて、GPUで実行されるミニプログラムの代わりをCPU
で行っていた。

この手法は最適化の可能性をひどく制限していた。プリミティブな命令一つ以上に
またがるどんな変換も極端に難しく、一命令内に限定した、比較的弱く、単純な最
適化のみがなされていた。

17 ： ◆FljYzA.syg ：2007/11/05(月) 01:25:50 ID:BoAoHrCW0

Appleは32ビットのPowerPCだけターゲットにしていたときは自分のJITに満足してい
た。しかし64ビットのPowerPCと、そして後に32ビットと64ビットのIntel CPUが加
わったとき、全ての新しいアーキテクチャ（そしてSSEやらSSE2やらSSE3やら更にい
ろいろ）のためにJITをアップデートするのは少し鳥肌が立つようになってきた。

弱い最適化をされたカスタムコンパイラの能力とターゲットCPUの増加？LLVMが助け
に来たぞ！Leopardでは各々の命令はLLVMの倍とコードのライブラリに含まれる（.
bc拡張子のファイルを探してみるといい）。バイトコードライブラリの呼び出しと
JITコンパイルを単独の簡潔な最適化されたネイティブコードにする？ノープロブレ
ム。LLVMはそのためにデザインされている。

予想通りだが、OpenGLでの使用ではLLVM本当にイカしている。JITさえなく、そのか
わりいちいち翻訳しなければならなかった古いシステムではある種の命令はApple
の古いカスタムJITより数百倍速い。多分AppleのOpenGLグループの最も大きな成功
は、オリジナルのJITコンパイラをメンテナンスしなくていいことだ。最良のコード
はコードを書かないことだから。

Leopardにおけるつつましい使用方法でミスリードされるかもしれないが、Appleは
LLVMについて壮大なプランをもている。壮大って？OS Xが使用しているgccコンパイ
ラの中身をそっくり入れ替えてLLVMの同唐物で置き換えるというのだろうか？この
プロジェクトは進行中である。まだ野心的でない？gccをすっかり捨て去って完全に
新しいLLVMベースの（しかしgcc互換の）コンパイラシステムはどうだろう？これは
Clangプロジェクトと呼ばれ、いくつかの印象的なパフォーマンスを得ている。特に
高速なコンパイルとリッチなメタデータはXcodeのようなGUIのIDEにとって多大な利
益がある。

18 ： ◆FljYzA.syg ：2007/11/05(月) 01:26:25 ID:BoAoHrCW0

このLLVMセクションが脱線していることは百も承知だが、Leopardで限定された用途
でしか使われていないにしてもLLVMはOS Xの将来にとってきわめて重要だ。実際、
iPhoneと他の（Macに限らない）OS Xプラットフォームの＜現在＞にとっても重要で
ありうる。

iPhoneがそのインターフェースで使われる視覚効果のどれだけをサポートしている
のかは分からないが、Core Animation, OpenGL, そしてLLVMベースのソフトウェ
アが比較的低速なGPUとCPUのプラットフォームで決定的に重要であると想像するこ
とは非合理ではない。Appleが最近LLVMのARMバックエンドにおいて精力的な仕事を
してたことを私は既に述べただろうか。そう、ARMはiPhoneで使われているCPUだ。
証拠は揃いつつある。

まあ、好き放題言わせてくれてありがとう。最近のLLVM開発について知りたいのな
ら、GoogleでLLVMのプレゼンをチェックしてくれ。このプレゼンはAppleの社員でLLVM
のリーダーのChris Lattnerによってされている。

19 ： ◆FljYzA.syg ：2007/11/05(月) 01:28:27 ID:BoAoHrCW0

Objective-C 2.0

64ビットのセクションで私は簡単にObjective-Cランタイムについて触れた。ここ
ではより詳しくObjective-C 2.0として知られるObjective-C言語について語ろう。
バージョン番号で区別するのは適切だ。なぜならObjective-Cの能力はこのコアの
ランタイムライブラリに強く依存しているからだ。このライブラリはクラスの内部
構造と拡張、メソッドの発行、そして2.0では、メモリ管理を扱う。

そうだ。Objective-C 2.0の最大のニュースはガベージコレクションをサポートし
たことだ。これは明示的に使用を行う機能であり、ガベージコレクションを使うか
どうかはコードごとに変えられる。ガベージコレクションが使われると、全ての手
動のメモリ管理関数は単純に無視される。これは全てのAppleのObjective-Cライブ
ラリが書かれているやり方であり、ガベージコレクションのオンオフどちらでも動
作する。

開発者にとってObjective-C 2.0は一般的な慣用記法を定型化するいくつかの機能
を含んでいる。例えばオブジェクトのプロパティに対するシンプルなアクセサとミ
ューテータを組み込みでサポートする。これらのメソッドを大量に書くことは退屈
だし、ミスの元だった。今では一番いい方法は分かっているので、Appleはシンプル
に言語の「ネイティブ」な機能としてプロパティを追加した。私が「ネイティブ」
と括弧つきで言ったのはそれがシンタックスシュガーであるからだが、少々の甘さ
はいいことだ。

20 ： ◆FljYzA.syg ：2007/11/05(月) 01:29:14 ID:BoAoHrCW0

Objective-C 2.0はここ10年かそこら変化のなかった言語にとって大きな進歩であ
る。Objective-Cはオープンソースであり、GNU Cコンパイラによってサポートされ
ているが、Appleは効率的にObjectie-Cを「所有」している。これはちょうどMicrosoft
がC#を所有しているのと同じやり方だ。Appleはこれまでこの言語の最大のユーザ
ーであるし、これを改良することに最大の利害を持っている。Objective-C 2.0
は所有の宣言であり、反論は見当たらない。Mac開発者は今のところすっかり受け入
れている。しかし私は未来を見ている。

Objective-C 2.0の導入において、Appleは注意深く変化を進めた。つまり、
Objective-C 2.0は「新世代の開発環境を達成するために開発に対する革命的な
変化にフォーカスしているのではない」と宣言することによって。これはまあいいが、
「新世代の開発環境」とは何だろう。

私はここ数年、これを反対にして、のど元まで出かかっている。動的で完全にメモ
リ管理がされた開発環境への移行というAppleの計画はなんだろうかと。私は2005
年にこのトピックについて、ひどく挑発的なタイトルで3度ブログにポストした。「
Copland 2010を回避しよう」と。（2010年というのは危機的状況のおそらく数年前
という意味）そこで私はObjective-Cにガベージコレクションを付けたところで長
期的には不適切だと悪口を言った。Appleは私に賛同したようだが、問題は未解決の
ままだ。

21 ： ◆FljYzA.syg ：2007/11/05(月) 01:31:55 ID:BoAoHrCW0

2010年やその後でも、これを読んでいるMac開発者で何の問題にも当たっていない人
がいることも分かっている。しかし他の面もあるだろう。プログラマが彼らが現在
使っている言語について常に考えているように見えることは、めちゃくちゃになら
ない程度には動的でなく、気が触れそうにならなったり危険にならない程度には動
的であることで、そのタスクがどれだけ抽象化されるかということなのだ。しかし
ここでごちゃごちゃ言うのはやめて、ブログで言うとしよう。

今のところ、Leopardに関係するポイントではObjective-C 2.0は良好だ。言語に
対する追加はObjective-Cの使用ををより快適にし、学習を容易にする。新しいラ
ンタイムはクリーンで、高速で、より強力だ。ガベージコレクションはそれが普及
すれば新しい世代のMac開発者を新たな本棚管理関数に従わせるだろう。絶壁が頭上
にあっても、少なくともAppleはスピードを上げて階段をつくり始める。私はただ、
我々が崖に達するまでに、到達すべき向こう岸があることを願うのみである。