WWDC 2005 相關討論請至此留言！

[ross_tt]

那麼，將來 x86 Mac 行 BIOS，開機時數 RAM，豈不沒有了 Mac 精神？

雖小弟也心心裏不爽，大呼哀哉，但 Mac 精神還在，失去了一部分就是了。

誰說 x86 Mac 開機的時候會數 RAM 了？

[cjtai]

那麼，將來 x86 Mac 行 BIOS，開機時數 RAM，豈不沒有了 Mac 精神？

雖小弟也心心裏不爽，大呼哀哉，但 Mac 精神還在，失去了一部分就是了。

誰說 x86 Mac 開機的時候會數 RAM 了？

我記得OS 9可以錄製一個QuckTime影片，放進系統檔案夾裡（確實是哪一個檔案夾忘了），可以在開機畫面時播放。

如果OS X也可以，錄製一個數RAM的畫面擺進去，不就會數RAM了。

[rlong]

這個主題短短幾天，已進入第九頁，應該已突破記錄了吧！

觀看人數也直線上升，加油！再接再勵！突破記錄可期！

不好意思，灌水啦！

[ross_tt]

我記得OS 9可以錄製一個QuckTime影片，放進系統檔案夾裡（確實是哪一個檔案夾忘了），可以在開機畫面時播放。
如果OS X也可以，錄製一個數RAM的畫面擺進去，不就會數RAM了。

畫面上看來如此，可是意義上不一樣

[janusng]

我記得OS 9可以錄製一個QuckTime影片，放進系統檔案夾裡（確實是哪一個檔案夾忘了），可以在開機畫面時播放。

如果OS X也可以，錄製一個數RAM的畫面擺進去，不就會數RAM了。

那要蘋果工程師，有本事在 BIOS 那 128kB 內，寫一個可以行的 Quicktime，才可能。

可惜的是，Quicktime 要等 BIOS 數完 RAM 之後，才可以 load 呢。
Apple 也可以學其他 vendors 如 Dell、聯想等，放張 16 色，不會動的蘋果圖片來騙騙人，等 OS load 入了，再放 Quicktime。

但願 Mactel 是用 EFI。

[進藤光]

誰說 x86 Mac 開機的時候會數 RAM 了？

天曉得，搞不好開機會想想看 SATA 上接了哪些硬碟？？提醒 EPA....
按 Del or F2 會進入藍色 BIOS.....

[icefox]

http://www.pbs.org/cringely/pulpit/pulpit20050609.html

這一篇是從蘋果以外的廠商角度來看這次事件。思考重點（不是上面那篇文章的重點，有我自己的意見）:

1. 其實 IBM 的 cell 應該可以做到很高的 computing/power ratio，不要忘記任天堂的主機有多小，其他三款也是，這些 game consoles 都需要在比電腦更惡劣的環境下運作（密不通風的電視櫃和無法容忍風扇噪音的客廳，理論上 STB 根本不應該有風扇），運算效能卻是非常驚人，而 MS 的 DTK 則是用 G5。這樣看來，整數運算部份 cell 和 G5 真的會差很多？或許真的有些缺乏某些指令，但這就是 RISC 的理論基礎--用其他的指令組合來補，況且有這麼多 cores，理論上對 threading 具有補強的效用。而 cell 的強項浮點和向量計算則是目前影音等數位生活應用程式的重心，拿來跑 Photoshop 和 3D 應該會很好用。cell 應該擁有運算超快，發熱量低的技術，幾乎是可以肯定的。

2. INTEL 和 MS 近年來在行銷上已經漸行漸遠，INTEL 應該不只看上 Apple 的 3%，看上的更應該是 Apple 本身的創新能力和運用創新的能力。

3. HP 欲振乏力已久，因而之前有 HP iPod 的事情。Apple 是否看上 HP 的供應鍊和通路體系？值得研究。畢竟 HP 本來和 iPod 的目標市場很難聯想到一塊，是否是拿 iPod 來練兵和測試使用者的反應？

4. 連 Mathematica 這麼複雜古舊的程式只要搞兩小時就搞定了，幹麼讓開發商有一年可以混？而且還有 Rosetta 可以對中小型程式頂一頂。或許是為了讓今年買 Mac Mini 的人不要太難過。但是在商言商，佈陣這麼久，不是在等死嗎？Steve 在想啥？

[the real unknown]

4. 連 Mathematica 這麼複雜古舊的程式只要搞兩小時就搞定了，幹麼讓開發商有一年可以混？而且還有 Rosetta 可以對中小型程式頂一頂。或許是為了讓今年買 Mac Mini 的人不要太難過。但是在商言商，佈陣這麼久，不是在等死嗎？Steve 在想啥？

iCon 大王一定是在想有多少笨蛋會相信 Porting 和他吹的一樣容易。尤其是一些不會寫程式又愛扯技術問題的專業笨蛋。

[JamesCooper]

原來這篇新聞和這次事件原來早就有關連了。

換作業系統，但不一定要換硬體核心！？

應該是吧！歷史經驗！

早年PC DIY圈為了處理器變革吵半天的時候，回顧英戴爾亞太區高層來台演講內容，以及演講後的Q & A時間，其實多少都會出現令人有種直覺上講不出來的感覺；

只可惜當時台灣PC仍以組裝約佔80%強，PC零售經銷商們較不盛行注意到大廠策略理論，反而是最遲鈍嗅到產業趨勢的一群

這一波可能會衝擊到過去較專注銷售apple硬體為獲利來源，店面形態的經銷商吧？

[icefox]

4. 連 Mathematica 這麼複雜古舊的程式只要搞兩小時就搞定了，幹麼讓開發商有一年可以混？而且還有 Rosetta 可以對中小型程式頂一頂。或許是為了讓今年買 Mac Mini 的人不要太難過。但是在商言商，佈陣這麼久，不是在等死嗎？Steve 在想啥？

iCon 大王一定是在想有多少笨蛋會相信 Porting 和他吹的一樣容易。尤其是一些不會寫程式又愛扯技術問題的專業笨蛋。

呵呵，其實大部分的 Open Source UNIX 程式 porting 真的很容易。我的 PB 上大概有上百支從 UNIX/Linux/BSD source port 過來的 library 和 application.... 遇到的問題多半出在 dynamic library 的處理方式，改一改就好了。如果程式一開始就乖乖用 Apple 的 XCode, SDK 和 framework。編譯到 x86 比這些 Unix tool 還要更輕鬆。其實比較麻煩的反而是在 Mac 下 cross compile x86 的程式，path 之類的東西要分得清楚，所以 Apple 直接給一台 x86 機器省得麻煩。

fink/darwinports 上已經有幾千隻從 UNIX port 過來的程式，寫這些程式的人大都沒有 Mac OS X，port 程式的人也都不是寫這些程式的人，你就知道 porting 其實很容易。

[jamesjan]

fink/darwinports 上已經有幾千隻從 UNIX port 過來的程式，寫這些程式的人大都沒有 Mac OS X，port 程式的人也都不是寫這些程式的人，你就知道 porting 其實很容易。

同事因為工作上需要用到freeradius,所以就把他的PB" 17拿來當RADIUS
跟在linux/FreebSD下面沒啥兩樣,不在意最佳化的人,就只要configure/make/make install,搞定

唯一不一樣的是Startup的script要去翻一下ADC or google
我還存在疑問是darwinports會幫你弄好startup的script嗎?? (現在手邊沒機器......)

[the real unknown]

Unix 的程式？要用 Unix 的程式你花那麼多功夫用 Mac 幹嘛？口口聲聲說 Mac/OS X 的精神是它與眾不同的使用者經驗。一提到軟體問題卻要搬使用者經驗最爛的 Unix port 來充場面。

最後一次：愈沒有用的程式 port 得愈快。

[icefox]

Unix 的程式？要用 Unix 的程式你花那麼多功夫用 Mac 幹嘛？口口聲聲說 Mac/OS X 的精神是它與眾不同的使用者經驗。一提到軟體問題卻要搬使用者經驗最爛的 Unix port 來充場面。

最後一次：愈沒有用的程式 port 得愈快。

哈哈，看你根本搞不懂 port UNIX/Linux -> Mac vs. ppc Mac -> x86 Mac 的難易度。
GUI 和 Carbon/Cocoa 呼叫部份根本不用擔心 port 問題。
最大的問題來自 Endian 和 Altivec..

還有，Mac OS 使用者早先深以為苦的 Windows Sharing 就是從 Open Source Unix port 過來的。呵呵，我看很多人倒是天天用勒。更別提整套在漂亮的 GUI 下工作得要死的 darwin / bsd...

[janusng]

最後一次：愈沒有用的程式 port 得愈快。

可能有用程式真的 port 比較慢，但是 TRU 可否啟發在下，有那些最有用的程式，還未 port 的呢？

[the real unknown]

他X的。說某些人笨蛋還真是高估了。Mac 換 CPU 需要 Porting 的工作是指那些還沒有在 Mac 上出現的軟體？那些蘋果五年下來一直偷偷在搞的 OS X 自己？那些沒人用的軟體？

還別的例子不提，剛好找那個蘋果搞了五年還是搞不定的 Window Sharing。你是在幫 iCon 大王說話還是在讓他出醜，還是你用 Mac 只是用來比誰 Port 的無聊程式多，從來不真的拿它做有用的事？

Unix 要在各種主機上跑，本來就 port 東 port 西的。愈 port 和硬體愈遠，效率也愈糟。反正那些程式都是些蛋頭在用，誰也不在乎它跑快還是跑慢。這和從來就只有在 big endian 機器上跑，為了克服 Mac 先天跑得慢，不能不盡量最佳化的 Mac 程式比，那個比較好 port？還是你根本沒概念什麼叫做「Mac 的程式」？還在用 vi 嗎？

[janusng]

他X的。說某些人笨蛋還真是高估了。...

小弟真的笨得緊要！以上多句，除了明白 TRU 大人在以「port 現有的 OS X 程式到 x86 不會易」來回應別人提出的「porting UNIX 程式到 OS X 不難」外，其餘完全不知大人在扯什麼！

[謝孟叡]

對我來說程式 porting 都是很難的。

[Watcher!]

他X的。說某些人笨蛋還真是高估了。...

小弟真的笨得緊要！以上多句，除了明白 TRU 大人在以「port 現有的 OS X 程式到 x86 不會易」來回應別人提出的「porting UNIX 程式到 OS X 不難」外，其餘完全不知大人在扯什麼！

喔！TRU 大人應該不是在吼你喔！可能是那個"冰狐兒“吧！哈！我來亂地！

[icefox]

怎麼會有人這麼白爛？再舉個例子吧。當年 Apple 的 OS 7 夠複雜夠獨特了吧？裡面還一堆 68K 的組合語言，Apple 只花了四五個月十多個工程師也都 port 到 486 上去跑了。稍有常識的都知道，這個難度比現在一般 AP 要換到 x86 上頭高了不知道有多少！

Mac OS X 的系統設計概念根本就不是以效率最佳化見長，它是以系統的彈性來彌補效率不高的 dynamic binding，所以 OS X 的系統效率其實不怎麼樣，而架在上面的應用程式想快也快不到哪去。以 NeXT 而言，十年前就把 portability 列為第一優先。更何況 Apple 捨棄效率最高的 IBM compiler 而就 gcc，更是把 portability 擺在 performance 之前！而這套 GNU tool chain，正是你最不屑的 UNIX 蛋頭工程師寫出來，被優秀的 Mac programmers 拿來天天用來寫被你捧上天的 Mac 程式的謀生工具。而且我管他 Steve 在講啥咪鬼東西，我在這邊所寫的都是一般 programmers 的 common sense！不信的話，有裝 XCode 的人也可以去翻翻 Apple 的 documents，有多少頁在提醒 programmers 要多多注意如何作 optimized code for PPC.

況且只要不用 Altivec (only for G4/G5 的應用程式少得可憐)，多注意 endian，程式要 port 到 x86 簡直易如反掌。除了這兩件事以外，C 程式 optimization 的技巧向來都是 universal 的，而且就算是有人閒到去 optimize for PPC 的 C 程式（通常能把 bug 解完出貨就偷笑了），和它是否容易被 port 到 x86 根本是兩回事。

別再出洋相了，真的！

[janusng]

...當年 Apple 的 OS 7 夠複雜夠獨特了吧？裡面還一堆 68K 的組合語言，Apple 只花了四五個月十多個工程師也都 port 到 486 上去跑了。...

未聽過，有佐證嗎？