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/
／ ＼:＼
.| カ ル ト ﾐ:::|
ﾐ|_≡=､´ ｀, ≡=_、 |;/ ／￣￣￣￣￣
. ||..(ﾟ )|￣|. (。) |─/ヽ ＜ おシュッ！シュッ！シュッ！ キンマンイトマンキン〜
|ヽ二/ ＼二/ ∂ ＼＿＿＿＿＿
. /. ハ - −ハ |_/
| ヽ／＿＿＼_ノ / |
＼､ ヽ| .::::/.|／ヽ /
. ＼ilヽ::::ﾉ丿＿ ／
/しｗ/ﾉ （ ,人）
（ ∪ﾟ ﾟ| |
＼ ＼__, | ⊂llll 日本でカルト宗教はやめられない〜 シュッ！ シュッ！ シュッ！っと
＼＿つ ⊂llll 南無妙法蓮ピィッ！ピィッ！ピィッ！ 南無妙法蓮華経財務しろ〜財務しろ〜
（ ﾉ ﾉ まんまん見て シュッ！ シュッ！ シュッ！
| （__人_） ＼ シュッ！ シュッ！ シュビデゥビドゥ〜〜
| | ＼ ヽ
| ） | ）
ttp://www.uploda.net/cgi/uploader4/index.php?file_id=0000021765.zip
一応、置いてあります……。
ttp://kb2m.sakura.ne.jp/log/honyaku/index.html
その他内部構造についてのいろいろ
これからの"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)で述べるバックアップ機能で使われる拡張属性の
セットの一つ。
てみろよ！これを保存して追跡するために、メタデータによる啓蒙を受ける前の
Appleがやってきたこと、アプリケーションが別々に実装してきたこと、その気違い
じみたダーティーハックを想像してみろよ。なんという無駄な努力、なんという独
特のバグ。もうたくさんだ！拡張属性は同じことをやるために、一ヶ所でデバグさ
れる一般的な方法を提供したんだ！」
Leopardはコマンドラインユーティリティも含んでいる。これは拡張属性を見たり書
き換えたりできる。これを読んだ人はは私のTigerのレビューで紹介したMarquis
Loganによるxattrというよく似たユーティリティを思い出すかもしれない。Apple
はオプションこそ違うが、全く同じ名前のユーティリティを作った。
Leopardでの他のコマンドもまた拡張属性を理解するようになった。例えばlsコマン
ドはパーミッション文字列の後に「＠」で拡張属性を示す。Leopardシステムをls
とxattrコマンドで探索するとAppleがファイルシステムのメタデータをどれだけ重
要視しているかが分かる。これはここまで。
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はいくかの
古いテクノロジーを非推奨にして後継テクノロジーを任命することで重要な進歩を
いくらか進めている。
Leopardは暗号化及び署名付きアプリケーションをサポートしている。このトピック
はある種の人々に対して警戒信号を発する。議論の多いMicrosoftのPalladium (NGSCB)
構想は数年前人々に警戒を引き起こした。これはMicrosoftがマーケットについて
判断を誤り、彼らが対象としていたセキュアなユートピアではなく独占企業による
鉄拳制裁という寒々とした未来をイメージさせるという結果になったからだ。今日
では「セキュリティ」という楽観的な美名で飾られて、勢力争いは警戒より楽観に
傾いた。
Leopardにおける署名プログラムについて理解するために、第一に言うべきことは、
これは上記に上げたようなものでもないし、そうたいしたものでもない。これでApple
（や他の誰か）があなたのシステムを全てコントロールするわけでもないし、破ら
れることのないセキュリティを提供するわけでもない。
じゃあ何をするのか？プログラムの署名はコードが同じであることを確認し、全く
改変されていないことを保証するものだ。その中身については何の保証もしない。
例えばAcme Inc.によって署名されたアプリケーションをダウンロードしたとしよ
う。それでできることといったら最後にウェブからダウンロードしたときのAcme Inc.
にあったものと同一であるということの証明だけだ。
消費者から見てこのテクノロジーの最も有用な例を示そう。今日OS Xのアプリケー
ションをアップグレードするとユーザーはそのたびにユーザー名とパスワードを取
得するためにキーチェーンにアクセスしていいか確認を求められている。これはセ
キュリティの機能としてはいいのだが、実際はMacユーザーに盲目的に「常に許可す
る」をクリックさせるよう訓練しているだけだ。ディスアセンブラを使ってプログ
ラムを走らせたり手作業でコードが安全かどうか確認することが平均的なユーザー
がやることだろうか？
ダーから提供された、新しいバージョンの同じアプリケーションであることを数学
的に証明する。その結果、ユーザーが調べようのない安全性について選択させるよ
うなダイアログの表示を終わらせることができる。
最終的には信頼するかどうかの問題になる。あなたがAcme Inc.のソフトウェアを
信頼するか、あるいはしないか。それはあなたが決めることだ。署名付きアプリケ
ーションだって、署名されていないアプリケーションと同様にあなたのハードディ
スクを消したりパスワードを盗んだりすることができるのだ。
しかし署名なしのコードとは違い、署名付きアプリケーションはインストール後に
変更されることはない。もしAcme Inc.製のアプリケーションが不正なことをした
ら、それはマルウェアによってアプリケーションがハイジャックされたためでない
ことは確かだ。別の言い方をすれば、行儀のいいコードはずっと行儀がいい。
書き換えようとすれば全く動かなくなる。
AppleはLeopardに同梱されている全てのアプリケーションに署名をしている。著名
なサードパーティーの開発者はそのうち同じようにすると思われる。
署名付きアプリケーションは自分を修正するアプリケーションという試みの終わり
でもある（例えば~/Library/Application Support/MyAppやその他のユーザー用
の場所にではなく、アプリケーションの内部にカスタマイズされたテーマファイル
をバンドルするとか）。こういうやり方はAppleによって推奨されてこなかったが、
これでまた避けるための理由が増えた。
・確実にコードに封印する
・封印が同一であることを確かめる
一方で以下のことをしない。
・特殊な権限の授与
・バグからの保護
・間違った信頼からの保護
・コピーの禁止
・Matrix世界における奴隷化
これはセキュリティを高める小さな一歩であるが、正しい一歩である。
ASLR
セキュリティのため、Leopardはアドレス空間ランダム化(ASLR)をサポートした。
名は体を表すのだが、ASLRはプログラムをメモリ空間上にランダムに配置し、不正
なプログラムが特定のコードがどこにあるか予測しづらくする。AppleはMicrosoft
がやっているようなセキュリティに関する偏執狂的レベルまでは達していないが、
OS XはWindows並のマルウェアの圧力からは逃れている。よって、やられてから反応
するよりも先にこういったアイデアを取り入れるのはAppleによってよいことだ。
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を使うのだ。
上におけば、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
で行っていた。
この手法は最適化の可能性をひどく制限していた。プリミティブな命令一つ以上に
またがるどんな変換も極端に難しく、一命令内に限定した、比較的弱く、単純な最
適化のみがなされていた。
た。しかし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にとって多大な利
益がある。
でしか使われていないにしても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によってされている。
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はシンプル
に言語の「ネイティブ」な機能としてプロパティを追加した。私が「ネイティブ」
と括弧つきで言ったのはそれがシンタックスシュガーであるからだが、少々の甘さ
はいいことだ。
る。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は私に賛同したようだが、問題は未解決の
ままだ。
がいることも分かっている。しかし他の面もあるだろう。プログラマが彼らが現在
使っている言語について常に考えているように見えることは、めちゃくちゃになら
ない程度には動的でなく、気が触れそうにならなったり危険にならない程度には動
的であることで、そのタスクがどれだけ抽象化されるかということなのだ。しかし
ここでごちゃごちゃ言うのはやめて、ブログで言うとしよう。
今のところ、Leopardに関係するポイントではObjective-C 2.0は良好だ。言語に
対する追加はObjective-Cの使用ををより快適にし、学習を容易にする。新しいラ
ンタイムはクリーンで、高速で、より強力だ。ガベージコレクションはそれが普及
すれば新しい世代のMac開発者を新たな本棚管理関数に従わせるだろう。絶壁が頭上
にあっても、少なくともAppleはスピードを上げて階段をつくり始める。私はただ、
我々が崖に達するまでに、到達すべき向こう岸があることを願うのみである。
どなたか、FSEventsとCoreUI
の翻訳を希望してます。
Mac:どうも、Macです。
PR Lady:そして彼はPCです。業界で最も売れているコンピュータプラットフォームです。
M:PC、これ、何？
PC:ああ、僕はPRレディーを雇ったんだよ。彼女はVistaについての問題を全部わかっているんだ。
PR:「問題」という言葉ですが、彼が言おうとしたことは、初期に採用したわずかな人が、ちょっと
した壁を乗り越えなければならないということを言っています。
PC:XPにダウングレードし始める人までいるんだからね。
Mac:そりゃあ・・
PR:「ダウングレード」という言葉で、そう・・「アップグレード」ということを意味しています。
以前の、もっと慣れ親しんだエクスペリエンスに。
PC:Leopardはずいぶんクールな機能があって君を使おうとスイッチしてる人もいるらしいね。
PR:・・・ノーコメントです。
Mac:どうも、Macです。
PC:アメリカ国民の皆さん、私がPCです。
Mac:どうしてこんな堅苦しいの？
PC:ああ、やりたいようにできないからと言ってVistaを断念している人がいるというからね。
それにXPに戻す人までいるんだ。
Mac:本当？ダウングレードしてるの？
PC:ああ、だがPCはあきらめない。
もしプリンターが動かなくなったら？そう！「新しいプリンターを買おう！」
MacのLeopardがたくさん新機能がある？そう！「無視だ！」
Vistaがあなたに何をしてくれるかではなく、あなたがVistaを買えるかを問おう！
Mac:うわあ、ずいぶんな活動家だね。
PC:実は僕、３週間前にXPにしたんだけどね。すごくよくなったよ。
"Boxer"はMCの調子が文字だとうまく伝わらないのでやめておきます。
Ask not your PC can do for you,
ask what you can do for your PC.
う〜ん、さすが、ケネディはいいこと言うなぁ（違うって）
"Boxer"も是非。
ttp://docs.info.apple.com/article.html?artnum=306907
（´・ω・｀） Macです
∧＿∧ 左コーナー
（ ´∀｀）＜ 仕事場出身 80ギガ ピーーシーー
∧＿∧ ＿∧
(（(◎ω◎)三ω◎)
(_っっ= _っっﾟ ﾋｭﾝ
ヽ ノ ﾋｭﾝ
( /￣∪
（´・ω・｀） PCどうしたん？
∧＿∧
(◎ω◎)＝つ≡つ Macが売れてる？にげねーよ
(っ ≡つ＝つ ボコボコにしてやんよ
/ ) ﾊﾞﾊﾞﾊﾞﾊﾞ
( /￣∪
（´・ω・｀） 商売なんだから競争だし
みんな自分のやりたいことできるコンピュータ買ってるだけだし・・・
∧＿∧
（ ´∀｀）＜ そーいえばー うちの弟もー この間買ったMac大ー好きーだー
∧＿∧
(○ω○) ・・・・
(っPCつ
/ )
( /￣∪
∧__∧
(´･ω･`) 乙です！
(つ旦と)
`ｕ-ｕ´
>>34
こういうスタイルもいいね！
GJ！ 爆笑しますたw
> （´・ω・｀） 商売なんだから競争だし
「これは競争じゃないよ」じゃまいか？
> ∧＿∧
> （ ´∀｀）＜ そーいえばー うちの弟もー この間買ったMac大ー好きーだー
細かいけど、「義理の弟(兄)」じゃまいか？
お願いします。
http://www.apple.com/getamac/ads/
おながいします
なんと言ってるのですか？(´･ω･`)
http://www.forbes.com/home/technology/2007/12/20/apple-army-hackers-tech-security-cx_ag_1221army.html
おねがいします。
そのコンピュテイング・プラツトフオームを多様化させて、
ハックされにくぃように、サイバ・セキュリテの強化パワアプを
ヤッてーるとの話でよ。
マクが関連記事の翻訳載せてたんだ
ttp://maku.ms/2007/dec/22/04_us_army_mac_security.html
納得
ありがとうございます
読みにくい文体だ・・・
昔むかし、BeOS と呼ばれる OS があった。衝撃的かつ革新的な設計の OS だ。
しかし、その大胆不敵なアイディアがすべて期待どおりになったわけではなく、
うまくいった部分だけでは、滅亡をもたらす非技術的要因の力から自らを
救い出すことができなかった。だが、BeOS は OS 業界に多大な影響を残した。
特に、そのファイルシステムや関連インタフェイスには四つの特筆すべき特徴があった。
ジャーナリング、
任意かつ拡張可能なメタデータ、
非同期通知機能、
メタデータの自動インデクスと、統合検索エンジン
こうした、連携して当時のいかなる PC OS とも異なるユーザエクスペリエンスを
もたらす機能である。特に Mac ユーザは、こうした機能を見てその価値を理解し、
自分の愛する OS にも欲しいと思ったものだ - BeOS の出荷が延期されたことを
知らなかったとすれば。
(Practical File System Design with the Be File System という本に、
これらの機能の歴史と実装が説明されている。フリー PDF もある。
http://www.nobius.org/~dbg/practical-file-system-design.pdf)
Mac OS X を作り出した。当初 Mac OS X には上記 BeOS ファイルシステム機能の
いずれもなかった。追加するようにという内外からの圧力には、NeXT/Unix 哲学に
慣れ親しんだエンジニアからの抵抗があり、そのようにして Mac OS X ファイル
システムの将来に関する、多年に渡る抗争(Mac 野郎 vs NeXT さん) が始まったのだ。
ある時点で (と伝説は語る……) Apple 内部の Mac 野郎たちが「勝ち」、
Apple は新たな道を歩み始めた。しかし Mac OS X ほど大きな船の舵取りには
長い時が必要となるものだ。傍観者の観点からすると、Mac OS X における
ファイルシステム技術の歴史は、NeXT さんたちから「非効率的」や「無駄」として
酷評された上記 BeOS ファイルシステムの機能をひとつひとつ実装してゆく
6 年の苦闘になぞらえることができる。
ジャーナリングは HFS+ に追加された;
Spotlight はメタデータ自動インデクスと統合検索エンジンをもたらした;
新しい拡張属性 API 群は任意に拡張できるメタデータを。
そして今、Leopard で、最後の一片が到来した: FSEvents フレームワーク
という形の、非同期ファイルシステム通知 API である。
技術オタクな Mac ユーザは、そのような API が Tiger に存在していたことに
気付くだろう; それこそが Spotlight を可能にしたものなのだと。
その /dev/fsevents 機構は、カーネルを通るあらゆるファイル i/o を追跡し、
関心を持つクライエントに通知する。これにより Spotlight エンジンは、自分で
わざわざ調査しなくても新規作成あるいは変更されたファイルをインデクスする
ことができるようになった。(調査 [polling] とは、何かが変更されなかったか
どうかを繰り返し尋ねる行為を指す。これは極度に非効率的で、ファイルシステム
全体にわたる変更を検出する方法としてはまったく使いものにならない。)
/dev/fsevents API はプライベートだった - だからといって生産的なハッカーの
おもちゃにならずに済むわけではなかったが。プライベートだったのには、
ちゃんとした理由がある。それはファイルシステム通知の仕組みと関係がある。
必要なファイルシステム変更をすべて知るために、通知機構は
ローカル i/o すべての通る隘路に存在する必要がある: カーネルだ。
しかしカーネルは厳格な時間およびメモリ制限で満ちた、気難しい女将である。
理想を言えば /dev/fsevents カーネルコードは各イベントをクライエントに
渡してからできるだけ早く次に進みたい。
通知待ちしていたプロセスは、いざイベントが来たときには別のことをしている
かもしれないのだ。これはユーザスペースでは仕方のないことだが、カーネルの
「今すぐ」最低限のメモリと CPU オーバヘッドでやらなきゃいけない状況とは
まったく相容れない。
たとえばこんなとき、カーネルはどうすれば良いのだろう。
2 秒間に 10000 個の変更が (ほら、ソフトウェアのインストールとかで) 起こった
のに、馬鹿でノロマなユーザスペースプロセスは他のことに手一杯でここ 3 秒間の
通知イベントをひとつもキューから引き出していない、とかいうときだ。
ああ、もちろんイベントをバッファする必要がある。つまり、保存しておいて
関心を持つ「すべての」クライエントが受け取りに来るまで待つのだ。
しかしバッファは無限ではない。カーネルでは特にそうだ。
では、バッファが一杯になってしまったら何が起こるか。
しかし考えてみよう、もしクライエントがキューの余地不足によりファイルシステム
操作でブロックされており、しかし通知を読んでバッファを空ける必要のある
別のクライエントは、その最初のクライエントのせいでブロックされているとしたら
どうなるか! やあ、デッドロックのお出ましだ。
残る唯一の手段は動的にメモリを割り当てることだが、それも問題の先送りに過ぎない。
単純に言うと、バッファできるイベントを制限して見落としを容認するか、
無尽蔵なメモリ使用に身を捧げるかのいずれかなのだ。
Apple は前者を選んだ。カーネルバッファは固定長で、遅いクライエントのために
一杯になれば、イベントは捨てられる。これは、お行儀の悪いクライエントがひとり
いると皆に迷惑がかかることを意味する。
だから、そう、/dev/fsevents はパブリック API にふさわしい候補ではない。
それでも効率的な非同期通知の必要性は消えない。どうするか。Leopard の
FSEvents フレームワークに入ろう。こいつは実用的なアプローチをとっている。
技術的な難題に対して FSEvents も「あらゆる人に、あらゆるもの」となることを
目指してはいない。そうではなく、視点をソツなく狭め、可能性の高いところに
注意を集中するのだ。FSEvents は全方位の「完全無欠」な解を出すよりはむしろ、
「80 パーセントの解答」を (ほぼ) 100 パーセントの信頼性で出してくれる。
* FSEvents の設計と実装 *
FSEvents の設計で主要なブレイクスルーとなるその点は、/dev/fsevents にある
もうひとつの弱点を考慮することにより達成されたように思える。
プライベートな /dev/fsevents API は、通知をリアルタイムにクライエントへ
配給する。これは API の最良の機能に見えるが、実際にはクライエントにとって
非常に重荷である。クライエントが動作していないときに起こったイベントは
見ることができないのだ。これこそ Spotlight のインデクスプロセスがシステム
ブート時に起動されて動き続ける理由だ。ファイルシステムイベントをすべて
受け取って処理するにはこうする必要があるのだ。
もし他に全ファイルシステムイベントを観察したいプログラムがあるとすれば
同じことをする必要があるだろう: ブート時に起動し、永遠に動作し続けるのだ。
おっと、その上ぜったいにクラッシュしないこと。なぜなら瞬時に再起動したところで
落ちている間のイベントは見落としてしまうかもしれない; /dev/fsevents は
プロセスを待ってくれないのだ。
常駐クライエント問題を解決することが他の多くの問題も消し去る、というものだ。
FSEvents がどう解決するかは以下のとおり。
/dev/fsevents API は非常に行儀の良い少数のクライエントだけをサポートする。
Spotlight はそのひとつである。Leopard では FSEvents もそうだ。
FSEvents フレームワークは、単一の常駐デーモンプロセス fseventsd に頼って
おり、そのデーモンは /dev/fsevents を読んで、イベントをディスク上の
ログファイル (複数。イベントが該当するボリュームのルート上にある .fseventsd
ディレクトリ内) に書き込む。おしまい。なんとも超ハイテクな解決ではないか:
イベントをログファイルに書くだけとは。退屈、現実的、しかし非常に効率的である。
FSEvents API を使いたいと思っているプログラムは常に動作している必要が「ない」。
好きなときに起動して聞けばいい、「よーし、前回から何か変わったかい？」と。
ログファイルのどこで自分がいなくなったかを知っている限り、FSEvents フレーム
ワークが (高速に) そこまで「巻き戻し」して正確に答えてくれる。
言ってもよさそうじゃないか。ログファイルはどれだけ大きくなるのか。
いつもファイルを作ったり編集したり消したりしていたらディスクが一杯になって
しまうのでは？ ログファイルは古いほうから消えていくのか。一年間動いて
いなかったプロセスがその間の変更を知りたがったらどうなるのか。
現実的であることは妥協を意味する。そう、fseventsd が /dev/fsevents の
集中砲火を浴びたとき、逐一そのイベントを書き込んでいればディスク容量は
すぐさま足りなくなるだろう。そうならないために fseventsd はもっと細粒度を
下げて、ディレクトリレベルでのみ変更を記録する。そこで FSEvents フレーム
ワークは、ただ「/hoge/dir で何か変更されたみたいです」としか通知できない。
クライエントは変更のあったディレクトリを自分でスキャンして、正確に何が
起きたのかを (そこまで興味があるとすれば) 見極めることになっている。
一般的なパターンは、ファイルシステムツリーの一部からの通知に登録しておき、
最初のスキャンをし、特定のディレクトリからのイベントを待ち、それが来たら
最新の状態と前回のスキャン時の状態とを比較するというものだ。
またスキャン、そして比較。この同じコードが FSEvents クライエントプログラムの
それぞれに必要であり、プログラマが不注意であれば競合状態が潜んでいる。
現実的であることには対価が伴うのだ。
しかし報いもまた大きい。もうデーモンプロセスは要らない; いつ起動しても、
前回からの間に何が変更されたか分かるのだ。行儀の悪いクライエントのせいで
イベントを落とす危険もない。好きなだけゆっくり読むがいい。ハング、クラッシュ、
再起動するがいい: 大丈夫、ひとつも見落とすことはない。
時間を遡って昔のイベントを見ることさえできる。
/dev/fsevents を含め、カーネルベースのあらゆるファイルシステム通知機構に
言えることだが、カーネルを通さないファイルシステムの変更も生じ得る。
たとえばリムーバブルディスクは別の非 Leopard コンピュータにつないで
変更されるかもしれない。元に戻したとき、カーネルとしては何が変わったか
まったくわからない。
FSEvents API にはこうした状況のためのコールバックがあり、効率よく
クライエントに通知することができる。「不明な変更がありますので、ご自分で
完全スキャンし直して、新しいイベントストリームの中から選んでください。」
そんなことを聞きたいのではない、とプログラムは言うかもしれないが、これが
現実だ。そのあたり FSEvents は正直なのだ。事実上、これも一種の信頼性と
言えよう。FSEvents はウソはつかないのだ。
変更しか保管されていないので、同一ディレクトリへ 30 秒以内に起きた複数の
変更は、ログファイル上でひとつのイベントに合体している。その結果はというと、
ディスク使いの荒いサーバ型の利用形態で 24 時間ぶっとおしだとしても、
fseventsd ログファイルは一日に 1、2 メガバイトしか増加しない。
通常の利用法ではほんのわずかであろう。
そりゃいいや、だってログファイルは「永遠に」保存されるんだから。
……うーん、まあ、可能な限りってことだけどね。FSEvents は、単調増加する
64 ビットのイベントカウンタを使う。何か悪意あるハックで数字を飛ばされたり
しない限り、これが一生のうちに一周することはない。ただ、もしも
一周してしまったり、ディスク容量が足りなくなったり、ログが明示的に
削除されたり (そのためのパブリック API がある) すれば、FSEvents は忠実に
バッドニュースを広める: 「申し訳ありません、完全スキャンの時間です。」
イベントは 64 ビットのイベント id で識別されるが、id は必ずしも日付や時刻と
一対一の関係があるわけではない。とはいえ FSEvents には、特定の日付および時刻に
対応する「おおよその」イベント id を尋ねる機能も付いている。
特定のボリュームに対する変更をまったく記録しないようにするには、no_log という
名前のファイルを .fseventsd ディレクトリに作ればいい。
なお、言うまでもないことだが FSEvents は Mac OS X のアクセス制御ルールに従う;
読み出し権限のないディレクトリに関わるイベントを受け取ることはできない。
>>クライエント
一般的には「クライアント」だがこっちの方が原語に近い上にｶｯｺﾖｽ
ありがとうございました！
http://movies.apple.com/movies/us/apple/getamac/apple_getamac_holiday_hp_ref.mov
早口で分からないよ……。
ありがとうございました。
原文読みかけて挫折していたので、日本語で読むことが出来てうれしいです。
原文はこちらですね。
ttp://arstechnica.com/reviews/os/mac-os-x-10-5.ars/7
何だろうね昔よりは日本語での情報充実してきたかな。
http://park15.wakwak.com/~concordia/cocoa_break/
C4[1]のビデオに字幕つけるとか
>これを読んだ人はは私のTigerのレビューで紹介したMarquis
Loganによるxattrというよく似たユーティリティを思い出すかもしれない。
ttp://www.flickr.com/photos/eddienull/sets/72157604008667022/
iPhoneの誕生
僕らは全員携帯電話を持ってた。みんな携帯が本当に嫌いだった、
ひどいものだったんだ。ソフトウェアは駄目。ハードウェアは
全然良くない。友人と話しても、みんな嫌いって言っていた。
誰もが嫌いって感じてたんじゃないかって。それで、もっと
パワフルで面白いものが絶対できるってわかっていた。巨大なマーケットだ。
毎年10億台の携帯電話が出荷されている、音楽プレーヤーに比べて
ほぼ1桁も違っている。毎年出荷されるPCの4倍の数だ。
大きな挑戦だ。恋に落ちるような素晴らしい携帯電話を作ろうと。
技術は既にあった。iPodから小型化する技術を。Macから洗練された
OSを。今まで誰も電話の中に、OSXのような洗練されたOSを組み込むことを
考えてはいなかった、それが本当の問題だった。僕らは会社の中で何度も
議論を重ねた、それが出来るか出来ないか。僕が決定を下さなくては
ならなかったんだ、そして言った、「やってみよう、挑戦だ」
ソフトウェアを書いている一番頭のいい連中が言っていた、出来ると。
ならば賭けてみようと。そして彼らはやってのけた。
http://money.cnn.com/galleries/2008/fortune/0803/gallery.jobsqna.fortune/index.html
続きは明日。あるいは誰かが続けてくれるんでもいいし。あるいはどっかのサイトで書かれてたら
それはそれで終わります。ミス指摘等あればよろしく。
期待して待ってます
ありがとうございます。
続きを楽しみにしてます。
これは楽しみだ！！
僕らは皆音楽を愛してたからiTunesが出来た。
iTunesで最高のジュークボックスをと考えて作った。
誰もが全ての音楽ライブラリを持ち運びたいと思っていた。
チームは本当にハードに働いた。彼らがハードに働いた理由は、
それが欲しかったからだ。そう、最初の数百人の顧客は僕ら自身だ。
ポップカルチャーとか人をだます、欲しくないものを欲しいと思わせると
いったことではない。僕らが欲しいものはわかっている。そして多くの人が
欲しいと思うかを判断するための正しい決まりごとを持つことも
うまくいっていると思う。僕らはそれでお金をもらっている。
将来起こることを、外に出ていって人に尋ねることは出来ない。
ヘンリーフォードの有名な言葉がある、
"顧客に欲しいものを訊いたら、彼らはこう言った、'速い馬だ'と"。
http://money.cnn.com/galleries/2008/fortune/0803/gallery.jobsqna.fortune/2.html
続きは明日。1日で1つやるので、面倒なんであれば2週間後に来れば全部終わってるんじゃないかと。
ミス指摘等あればよろしく。
僕らは市場調査をしない。コンサルタントは雇わない。
この10年で雇ったコンサルタントは1度、ゲートウェイの小売戦略を分析するためだ、
そのためAppleリテイルストアを立ち上げるときには、彼らがした同じ過ちをせずにすんだ。
だが自身のためのコンサルタントは雇わない。僕らは素晴らしい製品を作るだけだ。
iTunes Music Storeを作ったとき、コンピュータで音楽を買えることが
素晴らしいと思ったから作ったんだ、音楽業界を再定義しようなんてことはない。
予兆のようなものだ、全ての音楽はコンピュータで配信されていくだろうと。
コストがかかる理由は明らかじゃないか?音楽業界は巨大な収益がある。
電子的に簡単に送信出来るのに、全ての経費をもつ理由があるのだろうか?
http://money.cnn.com/galleries/2008/fortune/0803/gallery.jobsqna.fortune/3.html
家族旅行中のハワイ、コナでジョブズが独占インタビューに答えた！
会社の成功、ジョブズ無き後のAppleはどうなる等々！抜粋したものはこちら！
------
社員を動かすもの
僕らはそんなに多くのことをやる機会はないし、その全てが本当に素晴らしく
あるべきだ。なぜならこれは僕らの人生だからだ。人生は短い、すぐに死ぬ。そうだろう?
そう、これは自分の人生の中で我々が選んだことだ。日本の修道院に
入ることだって出来た。航海にも行けた。幹部の社員はゴルフをやったっていい。
会社を運営だってできたんだ。そして、僕らは全員人生の中でこういうことをしようと決めたんだ。
もっと良くしたい。さらに価値のあるものにしたい。そして僕らはそうなっていると考えている。
Appleで働きたい理由
理由、そうAppleで出来ることが他の所では出来ないからだ。多くのPC企業では
エンジニアリングが遠くに行ってしまった。コンシューマエレクトロニクスの企業は、
ソフトウェアの部分を理解していない。まさにAppleで作ることができる製品を
他では全く作ることが出来ない。Appleはひとつ屋根の下に全てを持っている唯一の企業なんだ。
MacBook Airを作れるところは他には無い、理由はハードウェアにとどまらず
OSもコントロール出来るからだ。それを可能にするのはOSとハードウェアの親密な
相互の連携だ。WindowsとDellのノートブックにはそんなものはない。
僕らのDNAは消費者のための企業だーすごいとかだめだとかの意見を出してくれる
個人の消費者。僕らが考えるのはそういう人だ。僕らは考える、我々の仕事は完璧な
ユーザ体験のための責任を取ることなのだと。ならば、それが水準に達していないなら、
それは僕らの失敗ということだ、わかりやすいしシンプルだ。
http://money.cnn.com/galleries/2008/fortune/0803/gallery.jobsqna.fortune/4.html
Appleには本当に有能な人材がいる。Tim CookをCOOに任命し、Mac部門を任せた、
見事に良くやっている。"ジョブズがバスに轢かれたら、Appleはもう
ヤバいぞ"、そんなことを言う人もいる。パーティにはならないと思うけど、
それでもAppleには本当に有能な人材がいる。取締役会で良い人間を選んでくれる。
僕の仕事は後継者になれるような経営幹部を作り上げることだ、そう、
僕がしようとしてることはそれだ。
過酷な評判
僕の仕事は簡単ではない。僕の仕事は物事をさらに良くしようということ。
会社の違う部分をまとめ、道を明らかにし、主要なプロジェクトのための資源を得ることだ。
素晴らしい人材を連れ彼らを動かすことが、さらに良いものになっていく、
将来のさらに積極的なビジョンが見えてくる。
http://money.cnn.com/galleries/2008/fortune/0803/gallery.jobsqna.fortune/5.html
楽しく読ませてもらっています。
dionが規制されてるようで最悪数日間書けないかもしれません。申し訳ない。
気長にお待ちしてます。
@@@
@@@@@
6´-ω-`) ｵﾂです
（⊇ ∩
Appleは300億ドル企業だ、だが中心となる製品は30もない。こんなことがかつてあっただろうか。
過去の素晴らしいコンシューマエレクトロニクス企業は何千もの製品を作っていた。
僕らは焦点を絞るようにしている。焦点を絞るということは集中するものを
決めることだと考える人がいる。だが全く違う。他の何百もの良い考えを捨てることなんだ。
慎重に選ばなくてはならない。
僕らが行ったことと同様、行わなかったことも本当に誇りに感じている。
わかりやすい例は長きにわたってPDAを作るという圧力を感じたときだ、
僕はある日気づいた、PDAを使う90%の人間は路上で情報を取り出しているだけだと。
情報を入力していない。すぐに携帯電話がそれをすることになる、そうなると
PDAの市場はさらに減っていく、それでは続けられない。
だから参入しないことにした。参入していたら、iPodに使う資源が無くなっていた。
おそらく出なかっただろう。
http://money.cnn.com/galleries/2008/fortune/0803/gallery.jobsqna.fortune/6.html
Appleでは25000人が働いている。そのうち10000人が店にいる。
僕の仕事は上位100の人間と仕事すること、僕がしていることだ。
全員副社長という意味ではない。一部は重要な個人の貢献者だ。
良い考えが出てきたとき、僕の仕事は、動き回り、他の人間が
何を考えるかを知る、話してみて、議論し、100人のグループで考えてみる、
異なった人間が一緒に違った視点で落ち着いて調べてみる、
そう、物事を調べることだ。
才能を見つける
年上の人間を雇うとき、能力は場に参加するための賭け金だ。本当に賢くなくてはいけない。
だけど、僕に取っての本当の問題は、Appleが好きになるか?ということだ。
Appleが好きなら、全てを大切にしてくれる。自分のためじゃない、
ジョブズのためでもないし、他の誰のためでもない、Appleのために最高のものをしたいと思うだろう。
リクルートは難しい、干し草の中から針を見つけるようなものだ。
我々はそういうことをやっているし、多くの時間をかけている。
僕は人生の中でおそらく5000人以上の雇用に関わってきた。
とても真剣に選んでいる。1時間の面接で十分に知ることは出来ない。
最後、結局はやる気に基づくことになる。
僕はこの人間をどう思うのか? 挑戦するときどうするのか? 何故ここにいるのか?
全員に尋ねている : "ここにいるのは何故?" その答えは探すものじゃない。
メタデータなんだ。
http://money.cnn.com/galleries/2008/fortune/0803/gallery.jobsqna.fortune/7.html
○Appleを
Microsoftを待たないといけないDellやHP、その他の企業がやっていることより、
革新を速めることが可能になった。Microsoftは、おそらくもっともな理由で、
独自のスケジュールがある。Vistaが7年? 8年? かかったとかね。8年待たなくては
いけないのなら、新しいハードウェアを必要とする新機能を入れるのは難しい。
だから僕らは独自の優先度を設定し、顧客の観点からもっと全体的にものをみる
ことが出来る。新しいものを取り込むことも出来るし、iPhone、iPodに合う
バージョンを作ることも出来る。僕らが独自で持ってなければ絶対に出来なかったことだ。
http://money.cnn.com/galleries/2008/fortune/0803/gallery.jobsqna.fortune/8.html
こういう話って、コンサルとかマーケの業界だと
すげぇ時間と手間をかけて市場規模調査やった結論として
出してくるもんだけど、それを直感一発で嗅ぎ取るのは
やっぱ非凡な人だなと。
> 僕の仕事は上位100の人間と仕事すること、僕がしていることだ。
これ、スティーブンレビーの本にも載ってましたね。
以下、本から引用
>「彼は社内の重要人物100人 - 社内組織図の上位を占めている重役という
>意味ではなく、ジョブズに言わせれば「船が沈みかけたときに、救命ボートに
>一緒に乗せたい」（たぶんそのボートに乗れなかった連中は、みな海の底に
>沈むのだろう）本当のエリート社員 - をリストアップし、「アップル100」
>という定期的会議を開いている
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
Apple TV @新Mac板 Part19 (497)
Cocoaはさっぱり!!! version.16 (662)
【多機能】Butler Part.02【ユーティリティ】 (325)
【CSシリーズ総合】Adobe Creative Suite 39【Mac】 (881)
【大量】ー用画像ビューアー Part9【放出】 (895)
[◎□|Дﾟ)っ] ＜ iPod 総合 Part90 (909)
--log9.info------------------
【アブストラクト】ABSTRACT MASH【マッシュ】 (217)
Luminous Orange/ﾙﾐﾅｽｵﾚﾝｼﾞ Part2 (771)
アマバン寄せ集めのライブのチケット高すぎ！ (203)
【国内】 シューゲイザー総合スレ6【Shoegazer】 (266)
【ｵｻﾚな街】3rd.StageｽﾚS【本八幡】 (780)
SAKEROCK・サケロック5 (646)
☆☆☆ advantage Lucy Part6 ☆☆☆ (778)
【廣嶋】 Psycho Candie ＆Julian 3 (580)
【ネハン】nhhmbase【ベース】 (611)
AJISAI part2 (651)
【笠井陽介に】 LINK part 3 【おまかせ】 (950)
BIGMAMA 5 (946)
【ダブチ】B-DASH Part15【ダブルチーズバーガー】 (814)
【SUPER】MASTER LOW IQ 01【STUPID】part11 (745)
ANATAKIKOU 4 (742)
シリカ (402)
--log55.com------------------
いい加減違法ファイル共有やめろよ
【百科事典】ウィキペディア第59版【Wikipedia】
WEB MONEY ウェブマネー Part3
【YAHOO!】ヤフーが重い時にageるスレ
なぜWikipediaは衰退したのか？
ウィキペディア Wikipediaって必要？
記事紹介|ウィキペディア（Wikipedia）校正廿校目
迷惑メール業者に宣戦布告してみた P2
