【辞めるって】アビー・テバニアン【本当？】

これからどうなっちゃうんだろう？

ソース
http://www.sfgate.com/cgi-bin/blogs/sfgate/detail?blogid=19&entry_id=3821

>>1



速報厨士ね

ていうか誰？

>>2
ごめんね

>>3
アップルの最高ソフトウェア（開発）責任者だよ

NeXT から Jobs にくっついてきた人だな。
ここのところ消息を聞かなくなってたが。

この人がいなくなるのはちょっと痛いんじゃないか？

UNIX板の某スレと重複になるけど、こっちにも書かせてくれ。

ジョン・ルビンシュタインが去るのもショックだったけど、それ以上かもorz
ハード部門とソフト部門の2枚看板を失ってしまうのか…
っていうか二人揃って同じ日に退社って、新事業でも起こすのかな？

今ではすっかり偉い人だけど、根は生粋のエンジニアだろうから、
どこに行ってもこれからも良い仕事をして欲しいな。

>>6
>>7
これからのMac OSが心配。
ビジネスとすればOSよりもアプリケーションのほうが儲かる。
Appleはその方向に比重を移すのかなぁ、と考えてみたり。

この人、今までのNextやOSX開発の中心人物でしょ。Machｶｰﾈﾙ開発の中心人物でもある。
ジョブズが、Next時代からｿﾌﾄｳｪｱ開発の中心に位置付けて、Apple復帰後は真っ先に
ｿﾌﾄｳｪｱ開発の最高責任者に抜擢したほどの男。

こんな重要人物が抜けて大丈夫かよ？それとも人材は心配しなくても豊富なのかな。


・Appleの初代CSOにテバニアン氏就任（CSO＝最高ソフトウェア責任者）
http://plusd.itmedia.co.jp/products/0307/09/ne00_avie.html

・「一部の開発者向けに初期段階のMac OS Xを配布している」
−−米アップルコンピュータ、Avie Tevanian氏に聞く(全文)
http://ascii24.com/news/i/keyp/article/1999/03/25/616095-000.html


http://www.remus.dti.ne.jp/~takahisa/flm/CWDX/part01.html
>アビーテバニアンは一途な人なんだよ。
>マイクロソフトからものすごい報酬のオファーがあったのに、あっさり蹴って、NeXTに行ったわけだからね。

ハードウェアに近い方の技術系の人だからな。
Mac OS X がそれなりの形になった時点で
自分の手を離れたと感じたんじゃないか。

OSの開発という点ではIntelアーキテクチャへの移行もおおよそ目処もついたしね

カーネルが変わるんじゃないの？

詳しくは分からないけど、
Intel化とAppleのメジャーシーン浮上に向けて更なるOSに対する信頼性が必要だし、
普通に限界だったんじゃないかなと思うんですけど。

>>3
>>13
誰かも判らなかったのに（恐らくどういう人かも解らないのに）、口挟むな
よ。

ほかに研究したいことができたかね。
Tiger完成時点から長期休暇取ったりして辞めるだろうなーってのは見えてたけど。

しばらく休養をとるとのことだし、引き抜きではなさそうだよね。
NeXT時代からジョブズの右腕としてやってきた人でもあるし、利で動く
人物ではないと思う。
もともとカーネルなどプリミティブな部分のOSの設計に興味がある人だから、
上でも書かれている通りIntel対応が完了した時点で自分の役割は終わったと
感じている可能性が高い。
個人的にはJordan HubbardがAppleに来たことで直接OSの開発に携われる
機会が減ったことがきっかけじゃないかと思うんだが。

数年前にも辞めるという噂が出たことがあるね。

次期OS(10.5)はLinuxベースと聞いた事がある。

はいはいワロスワロス。

アップルケアの１番が今日からiPodになってた。

>>18
釣られやすそうだな

気の優しい人らしいね
ジョブスの意見に異を唱えるときも恐る恐るだったって何かの本で読んだ

Mac OS Xの開発に関してはBertrand Serletって人が2003年から入れ替わりで
トップなんでないの？それに、Chief Software Technology Officerってちょっ
とお飾りっぽいもんね。

Bertrand Serlet
http://www.apple.com/pr/bios/serlet.html

Avie Tevanian Named Chief Software Technology Officer of Apple
http://www.apple.com/pr/library/2003/jul/08avie.html

使い心地には関心がなかった？
The Good, the Bad, and the Avie
http://daringfireball.net/2003/07/the_good_the_bad_and_the_avie

Serletって右目義眼なのかな。

でもアビーってジョブズと18年間一緒に仕事してるんだろ。
世界一の忍耐力の持ち主なのは間違いないな。

世界一鈍いのかもしれんぞ

鈍いんだったら例のエレベーターテストで即刻クビでしょ。
数多の天才たちを用済みになると無能扱いして追放してきた
ジョブズと10年以上仕事をしてきただけで神だと思う。

いやネタにマジレスされても。

スティーブ・キャプスが辞めたからってFinderが無くなりはしなかったわけで、
ちゃんと引き継ぎができてれば問題ないんじゃないの。

>>29
無くなる、無くならないの話をしてるんじゃなくて、
大丈夫なのか？って感じじゃないの？
ジョブスはその点、
「ジョブスがいなくても大丈夫」って感じだったんだろうけど。

キャプスか orz
スティーヴって付けられるとジョブスと見間違えてしまうがな

でも、辞めたら辞めたで、その後そのシステムが長く実権を握るということは
なさそうだね。OS9の切り捨てなどを見るに。

じゃーカーネル変わるの？うわっジョブならやりそうだなー

カーネルもマクドに転職

カーネル変わったらアプリはともかくドライバは書き直しになるぞ。
ただ、x86に移行したのでLinux/x86のドライバが使えるという利点はあるけど
いくらなんでもそんなことしたらデベロッパに愛想付かされそうだ。

LinusがAppleに電撃移籍なんてことになれば、それはそれで面白いが(w

ルビンシュタインも辞めることだし、ここで「独自ハードを捨て、PC/AT互換機に移行」
ということも考えられなくはないけど、それならx86の最初のバージョンからやっただろうし
タイミングを考えるとしばらくの間は無さそうな気がするんだけどね。

10年先を見るJobsならやりかねないなと思っただけ。
iPodがあったからx86移行にもふんぎりついた感もあるので、
将来的にOSXが大普及したら10のなかの1つの方向としてありそう。

確かLinus「はっきり言ってMachカーネルはクソだね」って言ってたよな

>>38
LinusはTanenbaumとの因縁があるからマイクロカーネルが嫌いなんだよ(w

>>39
へぇ〜。テクノロジーってのは、やっぱり開発ストーリーが面白いや。

むかーーーしのASCIIって、そういう読み物があって好きだったんだがなぁ。

>>12
>カーネルが変わるんじゃないの？

そーなのかーねる？

お…面白いっ！

>>38
それに関して、何処かで言い訳してた記事があったが。

>>40
ここで訳が読める。面白いから一読をお勧めするよ
http://www.oreilly.co.jp/BOOK/osp/OpenSource_Web_Version/appen_A/appen_A.html

Kernelの置き換えは不可能じゃないけど、相当困難らしい。
理由はCocoaは強くMachの設計に依存してるから（例えばプロセス間通信）だそう。

もしやるとすればドライバだけでなくAPIの再設計も伴って相当な期間を要するだろうし、
現在のOSXのターゲット市場を考えればメリットもあんまりないんじゃないかな。
サーバ市場に特化するとかじゃない限り、Linux Kernelを採用しなくてはならない理由は
余り無いと思う。特にこれからのマルチコア時代では元々MPに向いているMachの真価が
発揮されてくると思う。

噂話としては以前から時折話題に上っているけどね。

テバちゃん、ホンとはもっと前に辞めるって言ってたみたい。
結構仕事きついねんって言ってた。休む暇がないって。
でも、ジョブたんに引き留められて、OSX の基礎が出来るまでいるみたいな。

レオタードも完成に近づいて、目標達成なんじゃないかな。

>>46
>レオタードも完成に近づいて、

レ、レオタード？

そりゃそうだよなあ。OSX誕生から5年で5本も作らされてるんだから。

まさか毎回0から書いてるとでも

毎回ゼロではないにしろ、そこに居なくちゃいけない人って、どんどん怠けたくなるもんさ

写真家になったビル・アトキンソンを始め、Apple周辺の人はコンピュータとは
全く別の方向に興味が移るということが結構あるよね。
一年前にジョブズにやめる宣言して「〜が終わるまではいてくれ」と言われる。
で約束通りやめるんだけど、外から見るとずいぶん唐突に見える。

>>44
ありがと。ちと読みにくかったが、面白かった∩(´･ω･`)∩
こりゃええわ。

アビーの性格上、ヤバくなったらAppleに返り咲きっていうのもありそうだけどね。
なんだかんだで、NeXTやOSXに愛着があったらしいし。
まぁ、Appleの社員の出たり入ったりは、ジョブスもやってるぐらいだから、珍し
い事じゃないようなきもする。

45は理由が少し違うかと。
CocoaはSolarisやHP-UX、WindowsNTに移植されていた時代もあって、BSDやMachへの依存は小さい。
むしろ、スレッドやプロセス間通信のようなOSに近い機能が貧弱すぎるぐらいだ。
現状Kernelに食い込んでいるのは、Carbonの下層部分。
Cocoaもファイル関係は。直接BSDでは無くCarbonの上に乗っている。
この部分の作業ボリュームは巨大で、Next買収からOSX発売まで5年も必要だった。

Linuxの必要性が少ない事とか、移行の困難さは正しいと思う。

>>53
だけど役職まで与えてなわけで。
取締役会かなんかで、問題視されたんじゃなかろうかと心配になってきた。

>>54
>Next買収からOSX発売まで5年も必要だった。

その部分ってApple的には誤算だったのかな？当時の事は詳しく知らない。
iMacにOSX載せるには時期が早すぎただろうけど、もうちょっと全体的に
いろんな移行が早く済む計算だったような気もする。

日本でまだMacWorldEXPOをやってたころ、
会場で握手したおぼえがあるなあ。

相当誤算だったと思う。
・当初CarbonはOSXに移植されず、CarbonアプリをCocoaに移植するためのライブラリがメトロワークスから提供される予定だった。
・完成度の低さから移行に時間がかかりすぎると判断して、BeOSを選ばなかった。
・デバイスドライバ層を、NextStep時代とは違う物に書き直す事になった。
・描画エンジンも、NextStep時代のディスプレイポストスクリプトを捨てる事になった。

最初の話だと、NextStepにQuickTimeだけを移植して外観をMac風に変更して終わりのはずだった。
アプリは基本的にCocoaのみで、古いソフトはClassicを使えみたいな。

>>58
サンクス。なるほど。
初代iMacの時の青写真としては、相当のビッグバンを引き起こす予定では
あったんだろうなあ。結果、一段落までは10年近くはかかった感じだな。

それでもOSの移行作業を2回もやったって言うのは凄いことだと思うよ。

>>58
揚げ足を取るようで申し訳ないが

＞当初CarbonはOSXに移植されず

Carbonそのものが予定外だったんだよね。当初の予定ではYellowBox（今のCocoa）と
BlueBox（今のClassicみたいなもの）だけだったから。これだとソフトの全面的な書き換えが
必要なので開発者の支持を得られなくて、やむなく従来のtoolboxとソースレベルでの互換性の
高いCarbonを開発することになった、と。
当初の予定通りだったら新OSのリリースは早かっただろうけど、その後どうなったか分からんね。
MSのOfficeなどの主要アプリがYellowBoxに移植されなかった（または大幅に遅れた）なんて
ことになって、今頃Appleは存在しなかった可能性もあるかもしれん。

>>54
指摘?ｫ。勉強になるっす

素人考えで悪いけど、
MacOS X上で動作する完全な個別エミュレーターアプリ（今で言う仮想マシン？）
としてClassicを実現すれば良かったんでない？

下手にシームレス環境を作ろうとしたからCarbonが各レイヤーに食い込む後々移植性が
困難な構造になってしまったのかと。

結果的にClassic MacOS とあまり変わらない煩雑な構成になっちゃった？

いやそこは関係ない。
上で書いてる人が居るけど、OS X用アプリの作成を楽にするためにCarbonが採用されたんでしょ。

>>64
うん、だからそのCarbonがOS Xの深層部に食い込んでる事がNeXT STEP(OPEN STEP)
との差異であり問題だったんでないかな？と。 描画部分も含めてCarbonの影響が多いみたいだし。

Carbon排除はあり得ないってことか？

置き換えは進んでるんじゃない？Coreなんとかとか

>>63
なんか誤解があるような気がするんだけど、Carbonがカーネルの深部に食い込んでる話と、
Classicの見た目がシームレスなのは関係ないよ。

Classicは従来のMac OS用アプリをそのまま動かすエミュレータ。
見た目はシームレスに見せかけてるけど、従来のMac OSはOS Xとは独立して動いていて、
toolbox APIがOS Xに組み込まれているわけではない。

＞MacOS X上で動作する完全な個別エミュレーターアプリ（今で言う仮想マシン？）

元々のBlueBoxは見た目も完全に分かれていたんだよ。フルスクリーンモードでしか使えなかった
から、新OSと旧OSを2台のマシンで使ってモニタ切り替え機でチェンジするような使い勝手だった。
（Mac OS X Serverの1.xまではこの形式だった）

でもそれが使いにくいという意見もあって、今のような形式（当時は「透明なBlueBox」と呼ばれた」）
になっちゃった。どっちがいいかは意見の分かれるところだと思うけどね。
（個人的にはOS Xの一つのウィンドウとして旧OSが動くモードが欲しい）

しかし、、Carbon（CFMじゃないほう？）がけっこう色々なところで使われているっていうから、
てっきりIntel移植はできないものだと思ってたんですけど、
できるんですねえ。

>>66
54でも書かれているけど、現状ファイルまわりはCarbonがないと実現困難。
これは旧OSに由来するリソースフォークの扱いとかHFS+のサポートとか。
（例えばCarbonの無いMac OS X Server 1.xではHFS+は読み書きはできたけど起動ディスクに
できないとか制限多かった）

だからOS Xのバージョンアップの話が出るたびにFinderがCocoaで書き直されるという噂が
出るけど、当面は無いと思う。

全部がCocoaにならんでもいいけど、NSApplicationベースになって欲しいな＞Finder

ってことは、今Carbon切っちゃったら、Spotlightも使えなくなる？

>>63
別に俺だって素人だけど、アンタがいい加減な事を書いているのは分かる。
OSの深層部分（ｶｰﾈﾙか）になんでCarbonが入って来るんだよ。

Carbonｱﾌﾟﾘでは描画ｼｽﾃﾑに旧QuickDraw系のAPIが使われているものが多数ある。
何故かというと、行き成りQuartz系に移行させてしまうと、ｺｰﾄﾞの全面書き換えを余儀なくさせてしまう為。
Apple自身もQTみたいに旧QuidkDrawAPIに依存している部分があった。

TigerのQT7では、やっとQuatz系のAPIに書き換えみたいで、その恩恵でCoreVideoみたいなことが出来る。
OSXの構造を単純に表現すると、Darwin→CoreFoundation→Cocoa/Carbon→Aquaでしょ。

なんで「Classic MacOS とあまり変わらない煩雑な構成になっちゃった？」となるのか理由がわからない。
個人的には全然そんなことはないと思うけど。Apple自身も古いAPIは積極的に切り捨てたいんじゃないの。

Tigerに関して言えば、QuiｃkDraw系APIの使用は原則禁止みたいになったみたいだけど、
こういうの（古いｺｰﾄﾞの削除や使用禁止）を早くやり過ぎると、批判も多いんだろう。

因みに、フォトショップはQuickDraw系のｱﾌﾟﾘ。CS3では多分Quatz系に全面書き換えが必要になる。
その分、CoraImageみたいなOSX本来の能力をフルに発揮できるようになるんでしょ。

>>36
>>38
>>39
Linusは技術的なバランス感覚はあまり優れていない。
彼の妙な拘りのせいで、Linuxでは未だに標準ではクラッシュダンプが取れな
いし、raw disk deviceが使えない。

リソースフォーク自体も廃止の方向で進んでいるし、実際もう余り使わない。
それにSpotlightはリソースフォークなんか使ってねえ。

Tigerからは、UTIという新しい仕組みで構造管理されるようになっている。
Spotlightはその新構造のお陰で実現した機能。海外でもUTI機構は絶賛されている。

Adobeは昔はWin/Macでソース共通にしてたけど(写真屋で95%くらい)、Cocoaベースにしたらどうすんのかね？

HFS+じゃないとSpotlightって動かないんじゃないの？

UTIについては翻訳スレに書いてあったね。

ソース別で本気でMac用に詰めてくれたほうがいいものになるんだろうけど、
ソース別になるとMac版の開発はおざなりになりそうだな…。
Mac版にはない機能が増えたり、Mac版だけのバグが増えたり、リリースの遅れが大きくなったり…。

>>76
そこでCocoa (YellowBox) for Windowsの復活...

は無いな(w

流石アビーの名前のスレだけ有って、技術好きな人たちが集まりますね、
何気に良スレの予感。

ところで彼はCMUでコンピュータサイエンスの博士号を持っている人だよね？
大学に戻って教壇に立つっていう話とか、無かったのかな。本人が望めば引く手数多の気がするけど。

んでマイクロカーネルの講義をしているときに、Lで始まる名前の学生が受講していて（以下略

冗談はさておき、新会社を設立する？って話だし、どんなことをやろうとしているのかな。興味津々。

で、HMDTにこのネタでてたけど、xnuのソース引っ張りだして読め！に禿同！とか思ったよ
いや、結構Darwinのカーネルのソース読んでるバカは居ないともうけど、あの辺結構奇麗よ。
うん。尊敬できる感じの書き方。爪の垢くれ！って言いたい位（w

>>81
Palmの生みの親であるジェフ・ホーキンスは、なんかまた新しいことやってるし。
才能あるおっちゃんたちが、面白いことをやってくれると嬉しいね。

>>73
最初に素人だって断ってるんで、そう噛み付かなくても良いでしょうにw
私から見ればアタナは立派な専門家に見ますよ。
そうか！自分を素人と表現したのも不味かったですかね。
たんなる外野の一般人から見るとと書いた方がよかったかな？

Classic OSと同じで煩雑なって表現したのは確かにおかしいね。
Carbonが深層部に食い込んでるってのは一般人の私でもカーネルには食い込んでないと判るのであえて深層部としたんですよ。
描画やファイルシステムの根本部分がCarbonに依存してるってのも含めて書いたつもりです。
今は置き換えが進んでるってもの判ってますが。

NeXT STEPみたくMacOS Xも純粋に全部Cocoa（NeXTで言うとなんでしたっけ？）ベースだったら（また考え方や表現が変だと言われそうだが）
もっと進化のスピードも速かったのではないかなーと。いう一般人の妄想ですよ妄想。

あとまた噛み付かれるかもしれないけど
リーナス氏は確かに天才だと思うけど厨房ハッカーを絵に描いたような言動が嫌いだなぁ。
「糞」という表現を乱発したり「デジタル売春婦」とか何処のDQN厨房だよオマエはwって感じです。
ビル・ジョイの方が好き。 これも一般人のメモ帳の裏ですよメモ帳の裏。

>>84
>最初に素人だって断ってるんで、そう噛み付かなくても良いでしょうにw
それ何の免罪符にもなってねえ。
素人だったら何言っても思うなら大間違いだこのチンカス。

たしかに素人なのを自覚してるくせに、甘噛みされただけで
長文レスはウザいんで、もうちょっとスレを大切にしてください。

>>85
ずいぶん乱暴な思考だなぁ、専門スレや会員制のBBSならともかく
技術専門スレでもないココで素人は何も言う資格ないってかい？それも酷いね。
まるっきり嘘書いてるつもりはないんですけどね。

それと素人っていう言葉を免罪符にしてるつもりは無いよ。
自分だってスレ違いな場所で「初心者ですが〜が判らないのです。教えて下さい」って書き込み
が散々叩かれてるのを見て来てるし。
アナタの免罪符にならないってのは初心者の質問の仕方に対して「初心者ですが」って決まり文句とダブらせてるのでしょう？
それとも素人だけど、って提示しないでデタラメ書いた方がまだ叩かれないって事だったのかな？
んな無茶な事言うなやこのバカチンガw

こんな見解で如何でしょう？

>>86
自分みたいな素人が寄って来ないようにせめてsageましょうよ。
スレを大切にしたいならね。

まぁウザイのは確かなんで短めにしますよ。

誰か塩お願い

>>88
こういう方がスレの無駄使いだと思うんですが。

双方落ちケツ。

>>87
どうでもいいけど死ねよ

ほらほら、便乗しちゃいけませんよ。

よく「アプリをCocoa化しろ」って言う人いるけどなんかいいことあるの？Carbonに比べて動作が速くなるの？

むしろ遅くなったり重くなったりすることもあるみたいだな。
たぶん、一つの理由としては、ShapeSifterとか使って見た目のカスタマイズする人にとって、
CocoaでGUIが作られてないと見た目が変わってくれないみたいな都合があるんじゃないか？

>>93
Mac OS Xのアプリをゼロから開発する場合、CarbonよりはCocoaの方がずっとラク。
Carbonはほとんどオブジェクト指向でない、単なる関数群なのでコード量も多くなるし。
Cocoaをフレームワークとして、Cocoaだけじゃカバーしきれない部分でCarbonを
部分的に呼ぶのが現実的な解だと思う。
Cocoa化する利点は、開発効率が上がるってことであって、動作が速くなるということは
基本的には無いハズ。むしろ、Objective-Cのメソッド呼び出しはCの関数呼び出しの
数倍遅い（うろ覚え）ので、パフォーマンスとしてはCocoaアプリの方が遅くなる。
ただ、よく呼び出されるコードをしっかり最適化しておけば、気にならない。
元々Carbonで書いてあるコードをわざわざCocoa化するメリットは、
移行の手間を考えれば、あまりないように思う。

>>95
既存のアプリのCocoa化の話なので、結論は最後の２行？

>>93
あと、>>94も書いてるように、独自コントロールを作りやすいCarbonアプリと違って、
Cocoaアプリは標準のコントロールを使う場合が多く（カスタムコントロールを使う
場合もQuartzで描画するし）見た目が綺麗ということもあると思う。
Carbonアプリはフォントが不揃いだったり、コントロールのサイズがきちんと
調整されてなくて、みずぼらしいのも多かったから…。

>>96
まあ、そうなんだけど、前提知識を分かってない人も多いかと思ってw
語りたがりでｽﾏﾇ

詳しい人、何でCarbonがIntelでも動くのか教えてください。

>>99
10年近くの間に頑張ってちまちまと移植したんじゃね？

なるほどなー。
どうも、CPUの仕組みやプログラムの動く仕組みをよくわかってないので、そのへん不思議だ。

>>97
CarbonのカスタムコントロールもQuartzで描画出来ます。
１．CocoaはCarbonよりMacOSが用意しているコントロールが多い
２．Carbonアプリケーションを作る人はもともとQuickDrawに慣れていた
などから勘違いされているのだと思われます。

コントロールのサイズについてはMacOS Xになった当初のユーザーインタフェイスのガイドラインの出来が悪く
以前からアプリケーションを作っていた人ほど守らなかったというのもあります。

巨大なアプリメーカーほどCarbonの呪縛から逃れられないのは皮肉だなと思う。

何万行ってあるコード書き直すこと考えたら無理もあるまい。

というかここまでの話の流れだと「呪縛」という言葉を使うのが適切かどうかという話になるんだが。

>>102
言葉が足りなかったね。
Carbonアプリは、QuickDrawで描画したあんまり美しくないコントロールを
Mac OS Xでもそのまま使うのが多かったから、見栄えが悪かったってことを言いたかったのです。

誰か話をアビーに戻してよ。

デビット・カトラーがAppleにきます。

MSが手放さんわな。金で引き抜けるような人間とも思えんし。

難しい話は僕はわからないんだけど、みなさん、すごい。
ただのツールとしてMacを捉えるのではなくて
文化、言語、思想といった、人が作るモノに惚れてるのがわかる。
男が男に惚れるような、そんな感じかな。

支離滅裂だけれど、尊敬できる人にはついていきたいよね。

だから、みんなこうして>>1のスレについて行ってるじゃないか。
男が男に惚れてるわけだから、尻滅裂になるのもいたしかたあるまい。

さぁ。

別に趣味に没頭したい、らしいが何なんだろうな

別な趣味に没頭したいらしいが、何なんだろうな

>>110
うほっ？

>>1って春の人だったんですか？

男が男に惚れ　別な趣味に没頭し　うほっ？　春の人

ここは良いハッテンバスレですね

iLife for winでも開発してるかと思ってたけどIntel Mac出したから
いらねとかなったのかな。
これから対windowsへの全面戦争突入なのに・・・かなりの
戦力ダウンだろ。OSX 10.5とかどーすんだ。

Mac OS X 10.4 Tiger Kernel updates
http://arstechnica.com/reviews/os/macosx-10.4.ars/4
テバさんが抜けてもｶｰﾈﾙ部分は大丈夫だと思うよ。
今のOSXは将来を見据えて、計画的に強化されているから。
つまり、テバさん以外には手の出せないようなモノではなく、
簡単に改良できるような仕組みがTigerから導入されている。

>Tigerで施されたカーネルアップデート（翻訳スレより）

Mac OS XのカーネルはTigerにおいて非常に重要な変更を受けた。カーネルとはなんと
興味深い厄介者なのだろう。Machマイクロカーネルが伝統的なBSDスタイルのシステム・
コール・インターフェースに統合されている上に、IOKitのような、完全にアップルに
よって作られたテクノロジが加えられている。しかしながら、このレビューの目的、そ
れにほとんどの開発者の視点から見れば、カーネルとは複数の異なったインターフェー
スを持つ一つの実体とみなせる。

インターフェースの合理化

残念ながら、歴史的にMac OS Xに欠けているのはそういったインターフェースだ。（アッ
プルを含め）開発者は、自身のMac OS Xアプリケーションをサポートするためには、カー
ネルにからんだことをいろいろ行なう必要があるものだ。Mac OS Xの黎明期にアップル
にできたことは、そういったことが「可能」であるようにすることだけだった。のちに
は効率を考慮していくようになったが、しかしその各段階においては、開発者はやろう
としていることついていちいち、現在のメジャーバージョンではそれは「非公式」なや
り方だと警告を受けていた。

しかしながら、アップルもこの「非公式」の活動を思いとどまらせようとはしなかった。
アップルも、みなが必要とする機能のための確立された公式なAPIを自分たちが提供で
きていないことこそが、今の問題の根本原因だと認めていたのだ。

開発者に向けたメッセージはすこし奇妙なものだった。「アップルは皆さんがその種の
作業を必要としていることを認識しています。私たちは確立されたカーネル・インター
フェースをまだ用意できていません。それまでは、ともかくこのAPIとデータ構造体を
使って下さい。ただし次期Mac OS Xのメジャーバージョンでは、これらのインターフェー
スは変更される可能性があることを頭に入れておいて下さい。カーネルに触る部分を最
小限にできるのであれば、是非そうしてください」　アドバイスの最後の部分は決まっ
てこういう感じだった。「あなたがたがカーネルを触らなければいけない訳を是非教え
て下さい。そしてどうすればあなたの仕事を簡単にできるのか、私たちに是非教えて下
さい」

ほとんどの一般ユーザに知られることのない中、数年が経った。ときどき、ユーザは
Mac OS Xを新バージョンにアップグレードした際に、新しいプリンタードライバやVPN
カーネル機能拡張をダウンロードしなければならないことがあったが、その背景にはこの件
があったのだ。

さらに重要なことに、公式な確立されたカーネルAPIの欠如は、カーネルの一部分をサー
ドパーティ開発者が研究することを妨げていた。例えば、ファイル・システム・プラグ
インだ。この機能はMac OS Xカーネルが誇るすばらしい機能だったのに。10.0以前の
Mac OS X開発時にMacコミュニティの眼前にぶら下げられた、このたまらなく興味をそそ
るレイヤー化されたプラガブルなファイルシステムのことを思い出せるのは、おそらく
真にマニアックな読者たちだけだろうと思う。新しいファイルシステムをサポートする
機能は、動的にロード可能なモジュールとして切り離せるのだ！　しかも既存のファイ
ルシステム・モジュールに簡単に暗号化レイヤーを追加可能だと言うではないか！

こういった全てが有望そうにみえた。しかしこれらの機能の利点を享受できたベンダは、
アップル自身だけだった。ごくわずかなサードパーティだけが、ファイルシステム・プ
ラグインと同じくらいにミッション・クリティカルなものを、確立されていない、非公
式のカーネルAPIとデータ構造上に作り出しサポートしようとした。

この途上ではさらに別のことも起こっていた。開発者に対して強い警告をしていた一方
で、アップルはなんとかMac OS Xのメジャーバージョン間でカーネル機能拡張(kext)の
バイナリ互換性を保とうとした。この試みはかなりうまくいったが、非常に高い代償を
払う事になった。

バイナリ互換性を確保する過程で、アップルはたくさんの有益なカーネルの改良案をあ
きらめなければならなかったのだ。「確実な」パフォーマンス向上も、未実装のまま放
置するしかなかった。アップルはカーネルに新しい機能を追加することを著しく制限さ
れてしまった。アップルはカーネルを変更するにあたって非常に慎重にならざるを得な
かった。既存のサードパーティのカーネル機能拡張が、カーネルデータ構造のどの部分
を使っているかを判断する方法がなかったからだ。さらに悪いことに、いくつかのバグ
に至っては修正することすらできていなかった。それを修正すると、いくつかの重要な
カーネル機能拡張とのバイナリ互換性が壊れてしまうからだ。このような苦労を重ねて
もなお、OSのメジャーアップデートの際にはサードパーティ製カーネル機能拡張に障害
が発生することもあった。

この状況が望ましくないことは明らかだった。カーネル・パーツは触れることさえでき
ず、バグは修正もできない。カーネルの強化は後回しにせざるを得ないし、それでもカー
ネル機能拡張は障害を起こしてしまう。しかしこの間に、開発者は自分たちが必要とし
てカーネル関連機能をどう扱えばいいかを学んだし、アップルも開発者が最も望んでい
るものが何であり、それをどう提供するのがベストなのかを学んだ。

Tigerにおいて、アップルはついにカーネル・インターフェースのいくつかを世に出す
用意ができた。まず最初に、確立された、公式にサポートされたカーネル・プログラミ
ング・インターフェース(KPIs)がある。さらに、インターフェースのバージョン管理メ
カニズムもあるし、Panther以前の状態が二度と起こらないようにするための、マイグ
レーション・ポリシーも用意されている。

Tiger以降は、カーネル機能拡張は直接カーネルとリンクするのではなく、KPIとリンク
されるようになる。KPIは小さなモジュール群に分割されているので、カーネル機能拡
張は実際に必要なインターフェースとだけリンクすれば良いようになる。

KPIはそれぞれよく整備されたライフサイクル上に位置づけられる。以下のようなもの
だ。（訳注：これがマイグレーション・ポリシーです）

・サポート　　このKPIはソースでもバイナリでも、リリース間で互換性がある。
・非奨励　　　このインターフェースは今後のメジャーリリースでは削除される可能性
がある。使用時にはコンパイラが警告を発する。
・廃止予定　　このKPIを使って新しいカーネル機能拡張を作ることは、近いうちに出
来なくなる。しかしこのKPIを使用している既存のカーネル機能拡張のバイナリ互換性
はまだ保証される。
・非サポート　このKPIを使っているカーネル機能拡張は近いうちに動かなくなる。

この新しい仕組みで最も重要なところは、カーネル自体が変更可能になったということ
だ。KPIは、カーネルの変更が絶対に必要になったときには、「非サポート」というラ
イフサイクル上の最後のステージに向けてステージを下げ始めるだろう。

何よりもすばらしいことに、KPIの複数のバージョンが同時にシステム内に存在できる
と言うことだ。これにより、あるKPIの古いバージョンにリンクしているカーネル機能
拡張に影響を与える事なく、KPIのインターフェースを変更し新しい機能を追加してい
くことができる。すべてのKPIをきちんとサポートしつつ、同時にカーネルに山ほどの
変更を加えると言うことも夢ではなくなったわけだ。

論より証拠だ。Tigerのカーネルは根本的に変更されたが、Tiger以前の、カーネル機能
拡張の「悪い」やり方のほとんど全てをサポートできるだけの、十分なKPIが用意され
ている。確かに、Tigerにおいて動かなくなるカーネル機能拡張もある。しかしそれは
OSのメジャーリリースにはつきものなのだ。しかし今では、未来はもっと輝かしい。

（ところで、カーネルデータ構造に手を入れたり、カーネルに直接リンクするといった
機能はTigerにも依然残っている。しかしそういったことはめったに必要にならないし、
強く警告されている。アップルも明確に述べている。そのようなことをしているカーネ
ル機能拡張は、自身を特定のカーネルバージョンに、それも特定のメジャーバージョン
にではなく、まさにそのリンクしているカーネルのバージョンに依存させる事になる、
と。それでもなお、特定のカーネルにリンクすることがまったく適当であるという状況
もある。インハウスの、プロプライエタリなハードウェア開発などだ。それ故、その手
がまだ使えるということは良い事ではある）

カーネル機能拡張の世界には、まだいくつかすばらしい事実がある。しかも驚くべき事
に、ユーザーにとって（そうだ、ユーザーだ。開発者ではない）カーネル機能拡張をよ
りフレンドリーにするためのものだ。

カーネル機能拡張はいまや、人間に読み得る（しかもおそらくローカライズされた）製
品名称を持てるようになったのだ。この情報はダイアログボックスやGUI内のステータ
ス項目において使われることを想定している。自身の製品を実装するのに複数のカーネ
ル機能拡張を用意する必要がある開発者向けに、Tigerはカーネル機能拡張のグループ
化もサポートしている。そのため、複数のカーネル機能拡張をユーザー向けには一つの
製品として提供できるようになった。

（長いので、かなり飛ばして）
カーネルのまとめ

魅惑的なデュアル・コアCPUへの途上にあって、分割ファネルの廃止はTigerにおける最
も重要なカーネル改良点だろう。しかし確立されたカーネル・プログラミング・インター
フェースの導入こそが、Tigerカーネルの真のヒーローだ。KPIなしには、Tigerにおけ
る抜本的なカーネル構造の変更は不可能だっただろう。KPIはついに、アップルのカー
ネル開発チームが自分たちがやりたい事を自由に行なえるようにしたのだ。

64ビットサポートもよく紹介されるカーネル機能のひとつだが、Tigerカーネルはこの
領域において、やれるだけのことをやったと思う。ボールは今やユーザ空間のライブラ
リというコート上にあるのだから。


>という訳です。興味のある人が多いと思ったので、貼ってみました。

arstechnicaにTigerレビューが詳細に載ってます。
それを読めば、Tigerで導入された要素の多くが、Tiger以降を見据えた
ものであるということが分かるでしょうってば。

そんなわけで、俺はLeopardに物凄く期待している一人でっす。

Tigerレビュー（翻訳スレでほとんど翻訳されてます。検索してみて）
http://arstechnica.com/reviews/os/macosx-10.4.ars/1

じゃあTigerは手厚い置き土産になるわけですか。
ありがとうございます。

>>118-123
ためになる記事を貼ってくれてありがとう。凄く面白かった。

36 ：名称未設定 ：sage ：05/03/05 13:10:36 (p)ID:28Nlr4NU(4)
俺はティム・クック。通称縁の下。
なだめてすかして経営補佐の名人。
俺のような実務派でなければ百戦錬磨のトンデモ男の操縦役は務まらん。

俺はフィル・シラー。通称基調講演の時のコケにされ役。
自慢のカリスマ性のなさに、ジョブズ登場を期待してた観衆はみんなイチコロさ。
カロリーかまして、入社時から現在まで、どんどん太ってみせるぜ。

よお、お待ちどう。俺様こそジョン・ルビンシュタイン。通称チックコリア。
iPodチーム統率の腕は天下一品！
単なるNeXT時代からの腐れ縁？　棚からぼた餅？　だから何。

アバディス・テバニアン。通称アビー。そのまんま。
OSX開発の天才だ。NEXTSTEPの遺産でいくらでも食いつないでみせらぁ。
でもいつまで経っても副社長になれないのだけはかんべんな。

QuickTimeもカーネルに手を入れなきゃいけなかったからCocoaにくっつけるのが遅かったのかなぁ

>>127
Ａチームかよ
しかもモンキーかよ

記憶違いだった…　コングだね。

>>128 NEXTIME は簡単に作ってみせたのにな。

>>76でアドビどうするんだって言ってるけど、確かネイティブUIを
スクリプト言語でラップして使ってたと思う。LightroomはCocoa+Luaで
やってて、CS3の実験なのかもしれない。

>>127
Ａチームって応用範囲広いんだなぁ……。

アビーが消えて、またアップルから博士号がひとり減った。

まぁ、確かに一人減ったけど、あっちの技術者は博士号がデフォルトだから・・・
ただ、アビーが抜けたのは思い切り痛いけども。

辞めた理由が分かった。

アップル、Boot Campを発表
http://pc7.2ch.net/test/read.cgi/mac/1144240827/

>>134
PC上の計算で作ったものじゃなくて
人間が作るものが好きな僕としては
博士号ってのはどうでもいいんだけど
コンピュータはMacintosh
カメラ（レンズ）はCarl Zeiss
オーディオはBOSE
世間では変態と見られるかもしれない
それでも人が人のために作ったものを使いたいんだよね。
資産は人そのものなんだから。

コンピュータはMacintosh
カメラはミノルタ
オーディオはサンスイ
バイクはカワサキ

俺は変態だな……

変態度では138の圧勝だな。
137はただの洋物かぶれ。

>>137
>Carl Zeiss
ソニー系の印象しかなくて、色が青っぽそう。

>>138
バイクはビモータ。カワサキエンジンを拝借しちゃうまるでIntelマックなマシン。

なになに？変態ショー！？

コンピュータはMacとSPARCstation
バイクはBianchi（もちロードだ）
カメラはマミヤ
オーディオはMac・・・

ダメだな、変態度で勝てねぇ

折角だから俺も書いておこう

バイクは乗れない。というか自転車も。
カメラは京ぽんの10万画素
オーディオはサンワサプライ￥９８０

誰か俺に勝てる奴はいるか？

>>142
オーディオはMacってさ、McIntoshのこと？

どいつもこいつもビデオはベータだったと見た。

もちろんVHD

いや、そういうのをすっかり捨てちゃってMacにヘッドフォンだ（w
しかも100均のな。ここは思いっきりチープ。

>144
確かにβもあったよ。U-Maticもな（死
バックアップはQIC-150で取ってたしな。

で、Leopardって最大のトピックはBootCampが伏線で仮想化ってことかね？
仮想化可能CPUだっけ？いまのCoreDuoとかって。
だとしたら裏でSolarisだな（と、妄想を膨らませる）

>>139
洋物かぶれか。そう言われればそうかも。
まぁでもほら、Zeissの35mm SLRは京セラだしレンジファインダーもしかり。
デジカメはSony、中判はハッセル。
Zeiss厨だなぁ。って激しく板違いだった...

ともかく、どのようなMac OSになっていくのかな。
次はIntelMac買うしか無さそうだし、うーむ。

>>146
レオパルドではたぶんFront row みたいに画面が
すーと切り替わってOSが変わるんだよ。

それいいな

あえてリモコンで切り替えるとかな

勝手に起動OSがシャッフルされたらやだな…

>>86
>甘噛みされただけで

そう言えば、家の犬よく甘噛みしてじゃれてきてたな〜。。

技術家気取りのナルシストは見てて恥ずかしい。。

>>126
>>>118-123
>ためになる記事を貼ってくれてありがとう。凄く面白かった。
>


面白かった。。

>>152
それ、犬にナメられてんだよ

>>154
「面白かった」はおいらにとって最高の褒め言葉
まあ世間的にはもっと微妙な状況でも使うけどね…
決して他意は無いので、そこんとこよろしこ。

>>148
そこまでやってやる必要はないようにも思うけど……

あれば便利そうかなぁ。
でも、うちもMac/Winの両方があるけど、ほとんどWinマシンに
火がはいらなくなったなー。ゲームやらないせかな。

>>148
ファストユーザスイッチみたいにぐいんと回るのも捨てがたい。

Desktop Manager（仮想デスクトップアプリ）使って、
仮想デスクトップの一つにVirtual PCをフル画面表示、
仮想デスクトップの移動にファストユーザスイッチ風の
エフェクトを使えば、今すぐでもできるよ。

Desktop Manager（http://desktopmanager.berlios.de/）

Virtueのほうがアプリを特定の仮想デスクトップに固定出来たりして素敵
ユニバーサルバイナリになってるし

フエだかナンダカは強迫病でオナホール愛用者(　´,_ゝ｀)ﾌﾟｯ

>>155
>>>152
>それ、犬にナメられてんだよ

俺にすぐおなか見せてたけどな。
マウントポジションしてもしっぽ降ってたよ。

だからさー
アポ本体＝トヨタ
アポＪ＝トヨタカローラ福岡

ディーラーの営業かサービスマンなのよ。アポＪの社員は。
役割で理解できるだろ。トヨタカローラ福岡の社員が、
「俺はトヨタの社員だ。超大企業の一員だ」って言うの違和感あるだろ。

トヨタ社員でもなければ、トヨタ社員ほどの収入もない。まったく雲泥の差。
にも関わらず、トヨタの一員としての自覚と責任だけは押し付けられるｗ

このような不条理は、利口な欧米社会では通用しないが、
阿呆ば集まる日本社会では、常識として素通りしてしまうｗ

何がいいたいかっていうと、
利口な人間と、単なるアホの集団は違うってことだｗ

>>163
なぜ福岡

>>164
社員なんだろうよ
そっとしといてやれよ

Tellme Networks, Inc.の取締役に就任したらしい

吉田照美？

TM Network?

アビー・テバニアン氏、Tellmeの取締役に就任
AppleInsiderでは、元Apple Computer, Inc.のCSOである"手羽にゃん"が、カリフォルニア州
マウンテンビューに本社を置く、世界最大の電話のインターネット・アプリケーション・ネットワーク
を運営するTellme Networks, Inc.の取締役会に加わったと伝えています。

ネットアイドル テルミ

テルミ・・

そこで、ウォズがセグウェイに乗って登場ですよ

っs

ただいま最下層につき保守

NeXTが最初に採用した中の一人にアビー・テバニアンがいる。（中略）
ジョブズが彼の研究に”企業を賭ける”と言うのを聞いて気を良くしたテバニアンは、
博士課程を修了したらNeXTに入るようにというジョブズの誘いを受け入れた。
たが、NeXTを選択するということは、自社株購入権の付与に加えて、彼を100万ドル近くまで
評価してくれたマイクロソフトを断らなければならないということだった。（中略）
（マイクロソフト株の価値がなん倍にも跳ね上がった後の1991年、テバニアンは『
ウォール・ストリート・ジャーナル』に目を通して、ビル・ゲイツが約束してくれた
自社株購入権の現在価値を計算するのは苦痛だったと告白している）

STEVE JOBS & THE NeXT BIG THING より

金に目が眩むとはアビーにはがっかりしたな。

>>176
え？金を捨ててNeXTにはいったんだろ。

>>177

>>175 を読んだら逃した金を計算して悔やんでる金の亡者に見えるんだけどね。

Andy Hertzfeldって今googleなのな

http://money4.2ch.net/test/read.cgi/build/1157560468/32-45

sdqd