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

Connectixが買収された2003年は、エンタープライズ市場でサーバや
PCの仮想化がトレンドになると予想されてた頃で、VMwareも第2世代を
リリースし、企業向け製品として成熟してきた年。

当然MSもパーソナル／サーバの両市場で仮想化の可能性に気づいてて、
複数のホスト／ゲストOSとプラットフォームを扱った経験を持ち、
x86エミュレーションにも習熟してて、かつ買収前にVMware対抗の
「Virtual Server」の開発に着手していたConnectixの仮想化環境開発
チームを丸ごと買い取った。その成果が、今はこうなってる。

マイクロソフトの新仮想サーバー「Windows Server Virtualization」を見る
http://enterprise.watch.impress.co.jp/cda/special/2007/09/28/11230.html

Microsoft Virtual PC 2007（Vistaの仮想化サポートと連携）
http://www.microsoft.com/japan/windows/virtualpc/default.mspx

成熟製品としてのVirtualPC for MacはMacBUに移管されてしばらく
販売継続されたけど、上の2つを手に入れたMSは、ニッチ市場（Mac）の
新製品のために開発リソースを継続投入する意味なし、と判断したんだろうね。

ま、Mac版VPCの顧客にとっちゃ買収されて殺されたようなもん。ﾉｼ

ゲームに関しちゃJobsがゲーム嫌いって言う噂があるぐらいだしね。
それで売っていこうっていう気がないだけだろ。
とはいえ、Blizardには結構技術協力はしてるみたいだけど。

ゲームなんて時間を無駄に消費するだけ。
生きる目的を失いかけた亡者がハマる精神安定剤みたいなもんだ。

精神安定剤を必要としている人はいるんだ

実は精神不安定化剤という罠

>>954
うれしそうにCVGSを紹介してたぞ。

>>945

こんなの見つけたけど、どうなのかな?

>Using the IO HID Manager

>Mac OS X LeopardのHID Managerは、貴社アプリケーションがキーボード、マウス、トラックボール、ジョイスティック、コントロールなど
>Human Interface Device (HID)クラスのデバイスへのアクセスをサポートするプロセスを効率化します。
>ゲームにゲームパッドやジョイスティックのサポートを、会計アプリケーションにカードリーダーを、
>在庫管理ソリューションにバーコードリーダーを追加するようないずれの場合にも、
>最新のHID Managerが最適なソリューションをもたらします。
>この新しい機能を提供する新APIを作成したアップルのエンジニアから個別に技術的支援を受けられます。

http://developer.apple.com/jp/wwdc/sessions/

http://www.apple.com/hotnews/
iPhone向けサードパーティーアプリケーション

単刀直入に。我々はiPhoneで動くネイティブなサードパーティーアプリケーションが欲しい。
そこで我々は２月に開発者にSDKを渡すことを計画している。我々はiPhoneの回りに熱狂的な
サードパーティーの開発者コミュニティーを生み出し、何百ものアプリケーションがユーザーに
使用可能になることに興奮している。我々の革命的なマルチタッチインターフェース、強力な
ハードウェアと先進的なソフトウェアアーキテクチャによって、開発者にかつてない最高の
モバイルプラットフォームを形成できると信じている。

このSDKのリリース計画は２月までかかる。なぜなら我々は同時に２つの正反対な仕事をしな
ければならないからだ。一つは先進的でオープンなプラットフォームを開発者に提供すること、
もう一つは同時にiPhoneユーザーをウイルスやマルウェアやプライバシーの危険などから守
らなければならないこと。これは簡単なことではない。ウイルスやマルウェアは携帯電話にお
いて問題ではないという者もいるが、これは明らかに間違いだ。既に他の携帯電話に深刻な
ウイルスが存在しており、携帯電話ネットワークを通じて電話から電話へ密かに拡散するもの
さえある。我々の携帯電話が強力になるほどこれらの悪意のあるプログラムはより危険になる。
特にiPhoneは最も先進的な携帯電話であるのだから、とても目立つ標的となるだろう。

いくつかの会社は既に行動を開始している。Nokiaを例にとれば、最新の携帯電話では既知の
開発者として追跡可能なデジタル署名がない限りあらゆるアプリケーションを読み込めない。
これは「完全にオープン」な携帯電話からは一歩後退だが、正しい方向への第一歩だと信じて
いる。我々は、ネイティブにiPhoneの驚異的なソフトウェアプラットフォームをプログラム
可能な広範なアクセスを開発者に提供しつつ、同時にユーザーを悪意のあるプログラムから守
る、先進的なシステムについて作業している。

偉大なるサードパーティーアプリケーションが安全で信頼できるiPhoneの上で何年も動作す
るため、あと数ヶ月待って欲しい。その価値はきっとある。

Steve

P.S. このSDKはiPod touch用のアプリケーションも作成可能だ。

乙〜
ありがとうございます。

スティーブ最高!!

>P.S. このSDKはiPod touch用のアプリケーションも作成可能だ。
今のとこ、日本人にはここが一番肝心だな。

maclalalaでも、翻訳されていたね！！
蛇足だけど。

保守age

Piper Jaffray曰く「AT&TはiPhone一台あたり月18ドル」
http://www.news.com/8301-13579_3-9803657-37.html

AT&TがAppleと合意した収入の分配の詳細は開示されていないが、ある
アナリストはユーザーの２年契約の間にその額はiPhoneの販売価格を超
えると考えている。

Silicon Alley InsiderはPiper JaffrayのGene Munsterによ
るある研究結果を公表した。それによるとAppleはAT&Tとの契約により
iPhone契約者一人から一月当たり18ドルを受け取っていると推測される
という。Appleはこういった類の契約の存在は認めているが、iPhoneを
使ってAT&Tのデータネットワークを使用するユーザーからの収入からい
くら受け取るかという詳細については明らかにしていない。六月にMunster
はAppleは3ドルのiPhone契約者と11ドルの新規契約者を受け取ると
推測したが、彼はAppleの最近の収支報告の後に考えを改めた。

Musterはデビュー以来140万台のiPhoneをAppleは販売しており、
AppleがSIMロックを外されたと考えている25万台を差し引いた。この
115万台がAppleの第4四半期の収入になったと計算した。彼は1億1800万
ドルというAppleのiPhone関連の収入を用い、平均販売額に基づいて
ハードウェア収入を差し引き、AT&Tのデータ料金のいくらを受け取ってい
るかを推測した。

AppleとAT&Tの合意の下、iPhoneユーザーはAT&Tのデータネットワークの
使用に当たってAppleに一月当たり18ドル払っているかもしれない。

この計算は少々トリッキーだ。なぜなら6月と7月に販売されたiPhoneは9月
に販売されたものより明らかにより長期にわたって収入をもたらしている。
しかし彼は四半期の間iPhone契約者あたり月18ドルをAppleに支払っている
とした。

これは２年契約を終えるときにはAT&TはAppleにiPhone契約者あたり432
ドル支払うということになる。Silicon Alley InsiderはiPhoneの価格
400ドルを加え、iSuppliの試算によるコスト計算を差し引いて、２年の間に
565ドルの収入になると計算した。私はiSuppliの数字は疑わしいと考えて
いるが（彼らは研究開発コストについて無視している）、数字の正確さここでは
重要ではない。AppleはiPhoneをAT&Tのネットワークに留めておくことに
強力なインセンティブを持っている、たとえMusterの数字が完璧でなくても、
ということだ。

私はMunsterに電子メールでいくつかの質問を送った。２年間の契約中ずっと
18ドルであると考えるのは適当か、など。しかし返事はなかった。ある読者は
火曜日にiPhoneのブログでAppleはアンロックされたiPhoneからも収入を
得ていると正当な指摘をした。しかしこの携帯電話がAT&Tのネットワークで
動かないなら、テーブルからいくばくかの金がなくなっていくのだ。

楽しみにしていた記事がやっときた！
ということで、↓の翻訳、お願いします。

Mac OS X 10.5 Leopard: the Ars Technica review
http://arstechnica.com/reviews/os/mac-os-x-10-5.ars

>>969

Tigerの時、盛り上がった奴ですね。是非!!

Ars Technicaの翻訳を私からもぜひお願いいたします。

しかしものすごい分量あるからね。。そう気軽には頼めんわ。

まとめの部分の抄訳はここで公開されているけど。
http://maclalala.wordpress.com/2007/11/01/ars-technica/

たしかに、これ全部訳してというのは無謀ですよね。
個人的には↓が読みたいっす。（あまり減ってないけど･･･）
気が向いた順に訳していってくれればいいなぁっと。
是非お願いします。頑張ってください！

The Kernel
64-bit
FSEvents
Core Animation
Quartz GL
Core UI
Internals grab bag

>>973
>Quartz GL
の前半、QuartzGLの項を読んでみた。

Leopardでは、開発者がアプリ単位／ウインドウ単位でQuartzGL
（旧称Quartz2DExtreme）をイネーブルにできるようになったらしい。
あとは経緯の説明だった。10.4の時のレビュー訳読めば事情がわかるはず。

全部やる予定はないですが、ぼちぼちと。

序論
Tigerのレビューで，私はこう書いた

全体的に言ってTigerは印象的だ．これはAppleがこの12ヶ月ではなく18ヶ月
にやってきた仕事だとすれば，丸二年かければどれだけのことが出来るかと思うと身震い
する．

これは今日からちょうど２年半前のことだ．これには希望やら何やらが込められている．
LeopardはOS Xの中では（10.0を除いて）最も妊娠期間の長いOSだ．2005年に10.5
への高い期待を持ってからその期待は何年も何ヶ月も成長してきた．AppleのLeopard
についてのイライラさせる情報の隠蔽は炎を燃えたぎらせた．私のLeopardのリリ
ースを待つ精神状態は多分Mac信者の多くと同じだった．

多分平均的なMacユーザーは別の進歩したOS Xのバージョンを求めているだろう．18
ヶ月，二年半，誰が数えるというのだろう？我々信者は貪欲になり過ぎているのだろう．
何にせよ，Appleは押し売りが大好きで，MicrosoftがWindows Vista
をリリースするまでに5つもOS Xを出してきた．

期待を補正するためにMicrosoftをダシにするのはやめよう．Leopardは特
別だ．これまでに見たようにOSの美はその皮膚の奥にある．カジュアルなMacユーザ
ーはLeopardの価値をAppleのガイドツアーにあるような客寄せの機能で測る
だろうけれど，我々のような不健康なOSの虜はOSが「本当に」変わった部分が何か，内
部を探りに行くのだ．

インターフェースと内部というLeopardに対する二つ見方は，二つのの非常に異なっ
た評価を与える．機能そのものは，それが基づくテクノロジーやそれを使うようにするイ
ンターフェースではなく，ユーザーにとって実際に何をなすのかによって判定されるよう
な，この中間のどこかに存在している．

このレビューはこれら全ての方角を，深さを変えつつカバーする．他の全てのOS Xリリ
ースと同じようにLeopardは一つのレビューで全てをカバーするには巨大過ぎる．（
なにせTigerの内部構造だけでも1,600ページにもなったのだから）過去のレビ
ューのようにLeopardの個人的に最も面白い部分を選んで詳細に調べ，ついでにオ
タク以外の読者がArs Technicaのレビューにハマろうと思うように（やあ，保
護者のママ！）手ごろな全体像を示そうと思う．

オーケー，Leopard．君を見せてもらおうか．

page.5　カーネル

さあ，次は全く反対の方に進んで，OSのコアを見よう．より高いレベルから始めようかな．
最初は，カーネルだ．

2006年の夏，OS Xのカーネルの将来に関してちょっとした論争があった．これはよ
くあることだが，情報の空白によってもたらされた．このときAppleは（それまでは
していたのに）新しいx86カーネルのソースコードをリリースしなかった上にその理由
も説明しなかった．この虚無に対していろいろな予想がされ，当然私もちょっとばかり予
想してみた．

　私が考える，Appleがx86のOS Xのソースコードをリリースしない最も論理的な
　理由は，x86のTigerに乗っているカーネルは進化の袋小路にあり，後悔しても努
　力に見合わなくなったことだ．

　思うに，OS Xで行われる大きい仕事，カーネルにしろ何にしろ，ずっとLeopard
　に集中している．LeopardのカーネルがTigerのカーネルから大きく分岐した
　としよう．もしかしたら完全に新しいカーネルであると．例えば仮想化の効率的なサポー
　トなど．AppleはWWDCまで自分のカードを伏せておくだろう．それまではしばら
　くはもうすぐ消え去るTigerカーネルにソースを出すことはクリティカルパスには沿
　っていないのかもしれない．

私はある変なアイデアもあった．現在のMach/BSDカーネルを入れ替えるというもの
だ．これはあんまり突っ込んで欲しくないアイデアだが．しかしいつも通り，私はリスク
ヘッジを出来るほどには聡明（あるいは臆病）であった．

　私はWWDCで大きなカーネル関連のテクノロジーやアナウンスがなくても驚かない．つま
　りTigerであったような同種の進歩よりも大きな，カーネルの悪ふざけに対して切迫
　した必要は感じない．多分大きなアナウンスがないというのが最もありうる成果だろう．

WWDCは来たりて過ぎた（更にもう一回）．そしてカーネル関係の大きなアナウンスはな
かった．Leopardのカーネルは実際，これまでOS Xの歴史で最大の「Tiger
であったような同種の進歩よりも大きな」ものを含んでいた．これは悪いことではない．
（カーネルパイプの夢はOS X 11.0までとっておこうと思う）

カーネルの噂が炎上するのはOS Xは基本デザインの選択のせいでカーネルレベルでは性
能が悪いという考えに端を発する．これは長期にわたるミームで，疑わしいベンチマーク
と根拠のある（ただししばしば間違って適用される）コンピュータ科学の理論に基づいている．

ありがちなことだが，真実はそれほど劇的ではない．AppleのコアOSチームは，恐らく
予想されたところだが，グラフィックデザインチームとは別の極にいる．Appleの
カーネル技術者は特に実利主義的で，注意深く，懸命だ．とはいえOS Xのカーネル開
発プロセスの背後にある哲学をWWDCで話すために時間を使ったのだから，彼らもまた
人間である（彼らをつついたら血が流れないと思う？）．

Appleの焦点は，細かなベンチマークではなく，システムレベルのパフォーマンスにあ
る．カーネルチームの仕事は高レベルでソフトウェアがよく見えるようにすることにある．
もしあるちっぽけな一面でカーネルが10倍よくなってもユーザーに見える機能やタス
クのパフォーマンスには貢献しない．それは開発にかける時間の無駄遣いだ．ベンチマー
クの一等賞なんてクソ食らえだ．

これはAppleのカーネルチームが競争心がないということではない．しかしカーネルの
ベンチマークについて言うなら，ホームでやっていれば強いに決まっている．Linux
はLMBenchを使いたがるし，Solarisはlibmicroを，等々．これは
驚くようなことではない．ベンチマークの選択は最適化がどこに施されたかを語る．カー
ネルのパフォーマンスについて，Appleの「上から見て」どうか，つまり完全なOS
の上で動く実際のアプリケーションの動作がどう見えるかでカーネルのパフォーマンスを
評価するという決定は，カーネルのどの部分が最も注力すべきかに捧げられている．

一般的にOS XではそしてLeopardでは特に，スケジューリングとレイテンシが重
要だ．「速い」と「きびきび動く」は全く違うし，Appleが注目しているのは後者だ
．次からはLeopardカーネルからいくつかのハイライトを示そう．（核心的な詳細
は，いつもの通りソースコードにあるのだが…まあAppleがレポジトリを更新すれば）

カーネルのハイライト

LeopardカーネルはCPUのスケジューリングに秀でている．単一のフラットなプロ
セスキューから実際のハードウェア（デュアルコアのCPU二つであるとか）を反映した
階層的なキューに変更された．あるCPUから他のCPUにプロセスを移動させることは
パフォーマンス的にはよくない．チップ上のキャッシュは準備ができていないからだ．し
かし同じチップ上のコア同士はキャッシュを共有している．これを理解した上で生成され
たプロセスキューの階層はよりよいスケジューリングの選択を可能にする．

Leopardの仮想メモリはどのメモリがアプリケーションによって実際に使われている
かを瞬時に把握し，どれをディスクにスワップしても安全かを決める部分で進歩した．
ディスクにスワップする際にLeopardは（ついに！）スワップファイルを動的にアロ
ケートする．これはメモリが開いたときに若干のディスクペースの節約になる．

リソースの限界はTigerとそれ以前では破滅の原因だったのだが，Leopardでは
可能であれば動的になった．これらは開くことの出来るファイルの数や一ユーザーあたり
のプロセスの数などに及ぶ．もしこれらの限界につまずいたことがないのであれば，あな
たは幸運だ．例えばファイルをもう開けないとき，作業は最悪の形で終了する．

私はTigerでよくこの限界に出会い，限界点を広げようと涙ぐましい方法を取らざるを
得なかった．デフォルト値のいくつかはLeopardで大きくなった（例えばデフォル
トの一ユーザーあたりのプロセス数が100から266になった．私は常時2000以上だけどね！）．
更に，使用中のメモリのサイズなど以前は無制限だったリソースに新しい制限もできた．

Leopardカーネルは新しい「サンドボックス」システムを持った．これはある種のプ
ロセスに，セキュリティのためそれぞれ孤立して制限された環境を強制するものだ．Apple
の実装はmandatory access control（強制アクセスコントロー
ル，"Macintosh"でない略語の"MAC"がまた増えた）に基づいている．こ
れらのサンドボックスは控えめなUnixスタイルの，プレーンテキストで定義される（
例えば/user/share/sandboxに書いてある）．サンドボックスはLeopard
の多くのシステムに適用されている．Bonjour, Quick Look, Spotlight, NTPなど．

DTrace

多分Leopardカーネルの最も顕著な変化はDTraceの追加だろう．DTrace
はSunによって開発されたオープンソースのプロダクトだ．AppleのコアOSチー
ムは抜け目なくオープンソースプロジェクトの最良の配合を見つけて採用し続けている．
そしてSolarisからOS XカーネルにDTraceを移植する大仕事をやってのけた．
DTraceは長きに渡るカーネル開発の問題を解決し，Appleがカーネルハッカーに
限らない全ての開発者を助ける素晴らしい機会をもたらした．

DTraceがカーネル開発者をどのように助けるかを理解するために，次のシナリオを考
えよう．あなたはカーネルでプロセス生成に関わる場面で開発を行っているとする．あな
たの開発の間，新しいプロセスが生成されるたびに通知を受けたいと考える．そうしたら
カーネルにある新規プロセスを生成する関数を見つけてその関数の最初にログファイルに
何らかの情報を出力するコードを加えることになる．次にカーネルをリコンパイルして，
リブートして，そして仕事の続き．

残念ながらこのテクニックを使っている限り，少なくとも3回分あなたはハードコーディン
グされている．1）なんらかのデバグ情報，2)調査する場所，3）レポートのメカニズ
ムが必要だ．更に将来カーネルの別の場所に小さなデバグ用コードが必要になるが，同時
に全部のデバグフラグを立てたくはない．

だから，あなたがまともなプログラマなら，もっと普遍的な解決がある．何らかのデバグが
有用な場所全てで「今デバグする必要があるか？」を聞いてくる条件式でコードをラップ
することだ．

これはとてもよい解決のように思える．こういう断片がカーネルを埋め尽くすまでは．カー
ネルはその性質上すぐに，また頻繁に実行されるコードを含みがちだということを思い出
して欲しい．あるちょっとしたデバッグがオンかオフかを判定するコードがあって，それ
は1ミリ秒かかるとしよう．しかし10ミリ秒に一度そこが実行される場所に追加したの
なら，実行時間は顕著に増加する．そしてそのルーチンが一秒に何千回も呼ばれるんらば
，現実世界の時計で計れるほどの時間が無駄になる．これが何十万個のデバグ用のフラグ
だとしたら，最終製品でこんなチェックをしていられないのは明白だ．

明快な解決法はランタイムによって評価されるこれらの条件式を条件コンパイルに変えるこ
とだ．開発中でデバッグ有効なときはデバグ用コードの全てか一部を含み，製品版のビル
ドでデバグが無効になるとデバグ用コードはカーネルから全て取り除かれる．

単純化しすぎではあるが，これが伝統的なカーネルレベルのデバグ調査だ．開発に必要な全
ての診断を含んだ，ただし低速な特別のデバグビルドで作業する．あるデバグコードを追
加したり，有効にしたり，無効にしたりするのにコンパイルし直して，リブートする．も
しうまくいけば，最適化された，デバグコードを含まない製品版のカーネルをコンパイル
する．

DTraceはこのような環境に訪れた．次に挙げる一見不可能な機能の組み合わせを目論
むものである．

・リコンパイルなし．デバグ用コードの有効化と無効化を動作中のカーネルにすぐ適用できる．
・使用しなくてもオーバーヘッドほとんどなし．無効化されたデバグコードは製品版のカー
ネルビルドに残っていても構わないほどに小さい．

これを読んだプログラマは，自己書き換えプログラムのことを思い出して震え上がるだろう．
しかし目を閉じて，僕に身をゆだねてくれ．これは本当に役に立つんだ．とてもうまく．

DTraceは単純化されたプログラム言語である「D言語」（Digital Mars
のじゃないよ）をサポートする．これはプローブを定義するのに使われる．新しいプロセ
スが出来るたびに通知を表示する例を示そう．
（略）
これはこのような出力になる．
（略）
もうちょっと複雑な例を示そう．これはプログラムがstat()システムコールを行うの
を待って，カーネルからこの呼び出しが実行されるのを追跡する．
（略）
出力をまとめるとこうなる．
（略）
動いているのをみると，(エリック・レイモンドじゃないけど）魔法と区別がつかない．こ
のひねくれたCのような言語を使ってスクリプトみたいな短いテキストファイルを書いた
だけなのに，カーネル全部に手を突っ込める全権を手に入れたんだ．（言うまでもないけ
れど，DTraceを実行するにはrootになる必要がある）

D言語は条件分岐も，サブルーチンも，繰り返しもサポートしない．これはよいことだ．な
ぜなら間違って無限ループや再帰呼び出しをカーネル中でやってしまったらちっぽけなテ
キストスクリプトがやるべきことではないから．DTraceをカーネルのメモリやCPU
のレジスタ，任意の関数の呼び出しには使えない．

----
ちょっと今日は時間切れです。カーネルの続きとLLVM、Objective-C 2.0はやる予定です。

乙です
ありがとうございます〜

乙です！

乙です。どこにもない情報だから勉強になります。

一部修正した部分も含めて、カーネルの続きです。


動いているのをみると，(エリック・レイモンドじゃないけど）ハイテク過ぎて魔
法と区別がつかない。このひねくれたCのような言語を使ってスクリプトみたいな短
いテキストファイルを書いただけなのに、カーネルのあらゆるところに手を突っ込
める全権を手に入れたのだから。（言うまでもないけれど、DTraceを実行するには
rootになる必要がある）

D言語は条件分岐も、サブルーチンも、繰り返しもサポートしない。これはよいこと
だ。なぜなら間違った無限ループや再帰呼び出しはちっぽけなテキストスクリプト
がカーネル中でやってしまったらやるべきことではないからだ。DTraceをカーネル
のメモリやCPUのレジスタ、任意の関数の呼び出しには使えない。

しかしこういった制限の範囲内ではDは全く強力だ。Dは通常のC/C++の型、集約
関数、ローカル変数、スクリプトの引数は$1から$Nまで、BEGINからENDまでのブ
ロックなどシェル／awk風の一連の文法があり、それどころかASCII文字でのヒス
トグラムさえもサポートしている。これは使っていてとても快適だ、特にリコンパ
イルとリブートに比べたら。

忘れないで欲しいのだが、これら全ては特別でないノーマルなLeopardで動くのだ。
DTraceは全てのLeopardシステムに含まれる。オプションでさえない。これは開発者
が全てのユーザーが持っていると考えて良いという意味になる。DTraceはプレーン
テキストなので、困難な問題を電子メールでデバグすることが千倍も楽になる。
（デバグシンボルとその他のメタデータを全て備えたカーネルのビルドはそれでも
有用だ。DTraceはこれらを置き換えるものではない。DTraceが行うのは以前のレベ
ルではあり得なかった柔軟性を従来手法の上に提供することだ。製品として出荷さ
れたカーネルにさえ維持される柔軟性を）

Developer Toolsをインストールしたら、あなたはGarage BandのようなGUI
アプリケーションを使えるだろう。これは個別のアプリケーションもシステム全ての
デバグにも使える道具だ。このアプリケーションはずっとXrayと呼ばれていたことは
アイコンでも分かるのだけれど、確実に弁護士の絡む話のせいで今ではInstruments
と言われている。でもこのレビューではXrayという名前のままで呼ぶことを許して欲しい。

もう驚くことではないが、最も強力な道具の多くはDTraceに拠っている。GUIでカス
タマイズされたDTraceベースの道具を作ることもできる。それに一連のアクション
を記録したりやり直したりもできる。うーむ、自動化されたGUIベースのパフォーマ
ンス追跡テストとは。

DTraceとXrayを使うとこんな疑問が涌いてくる。「私のアプリケーションは起動時
にいくつのファイルを開くのだろう？」「ある関数は何度呼ばれるのだろう？」
「結局私のアプリケーションはどれだけメモリをつかうのだろう？」DTraceとXrayは
以前ならこれらの疑問に答えるためにやらなければらなないうんざりするような作
業をほとんど自明で（私に言わせれば）楽しいものにする。Xrayを見たMac開発者が
自分のアプリケーションのログをとるため使わないなんて信じられない。

この新発見の能力はアプリケーションを助けるのではなく、より良く、速く、安定
するように導く。サードパーティーの開発者からApple自身まで。そしてこれは全て、
Sunが作った、縁の下の力持ちの、オープンソースの低レベルカーネルでバグフレー
ムワークに依存している。

カーネルの現状

Tigerにおいて、カーネルのAPIを明確にし、進むべき道をクリアにすることでApple
はNeXTのルーツからOS Xの未来へカーネルの移行を完成させた。Leopardはこの道
を進んだ初めての大きな一歩になる。DTraceの追加は最も顕著な変化だ。DTraceは
開発プロセスにおける、また拡張可能性とユーザーに使用可能なアプリケーション
の品質によって、最大のインパクトになるだろう。

残りの全ての変化は「ほぼ同じ」だが、これは良いことだ。パフォーマンスの最適
化、スケーラビリティの向上、標準へのより良い準拠、全て適切で保守的な程度だ。
DTraceの追加はLeopardの他の部分も助けたはずだが、DTraceがOS Xの速度を上げる
のにはまだ時間がかかる。真の報酬は次のメジャーバージョンのOSになるだろう。
そしてそれはポストDTraceワールドで全て開発されるだろう。

乙でっす。

神光臨！

おつかれさまです！

翻訳ありがとうございます。
とても読み応えがありますね。

立たないかと思ったんですが・・・

Mac関連ﾈﾀをそれはもう凄まじい勢いで翻訳するｽﾚ7
http://pc11.2ch.net/test/read.cgi/mac/1194073058/

梅

UME

bury

ｳﾒ

1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。