Comments on: Linux 创始人批评 Mac OS X 的文档系统

By: asimo118

asimo118 — Fri, 08 Feb 2008 23:29:59 +0000

Bento 還不錯用，是一套「個人用」資料庫軟體，只要善加利用，可以變成個人的 CRM 系統。不過，Bento 畢竟是一套「個人用」軟體，一些功能上略顯得陽春了點。

By: Lawrence Li

Lawrence Li — Fri, 08 Feb 2008 22:50:17 +0000

Bento 我没用过呢，很多人觉得像是 iWork 套件里「漏掉」的数据库软件。不过开发它的 FileMaker 不久前已经独立出来不属于苹果了。

By: 张亮

张亮 — Fri, 08 Feb 2008 22:37:29 +0000

呵呵，多谢阿西摩兄。
另外，我开始琢磨，是不是我们该设一个问答区？
比如，我刚才看到苹果出了一款叫bento的管理软件。究竟好不好，似乎提问，比猜测更有价值。

By: asimo118

asimo118 — Fri, 08 Feb 2008 15:22:20 +0000

@Lawrence Li :
是的，是這樣解的。
我文中所提的檔案，是指單一檔案，而非整個資料夾。

By: Lawrence Li

Lawrence Li — Fri, 08 Feb 2008 13:54:01 +0000

我想 asimo 的叙述可能容易引起一些误会。按照我对 Siracusa 文章（即 asimo 给出链接的 Ars Technica 那篇）的理解，比如说你的 ~/Music 文件夹是 2G，然后你加了一首 3.9MB 的 mp3 进去，是不会导致这整个 2G 的 ~/Music 被重新拷到时光机硬盘的。这种情况是限定在单个文件（即 asimo 文中的「檔案」，英文里的 file）之上，比如你有一个 600MB 的 AIFF 或 WAVE 声音文件，然后你只是把其中两秒的音量加大了一点，时光机下一次备份时就必须把 600MB 整个拷一遍，而不是只拷那两秒。
不知这个说法正确吗？

By: asimo118

asimo118 — Fri, 08 Feb 2008 08:49:07 +0000

HFS 最早逝在 1985 年的時候發表的，而 HFS+ 則是在 1998 年發表。
HFS 最最最令人詬病的就是這種資料結構將所有的資料全部存在在同一個資料結構中。而這種資料結構不僅會導致系統 loading 加重，也會耗損掉無謂的儲存空間，嚴重的情況下，還會導致 hugging。雖然 HFS+ 改善了一些 HFS 的一些問題，但是資料結構上的問題並沒有徹底解決。
我舉一個最簡單了例子來說好了，OSX Leopard 10.5 上的新功能 Time Machine 這個備份功能來說好了。Time Machine 的備份是依據檔案資料上得一些差異性來決定是否備份。而 HFS/HFS+ 造成最嚴重的問題就是，假設，你今天有的 10MB 的檔案，而當中你只有對這 10MB 資料當中的 1MB 做了修改。合理的作法，應該是需要在備份這 1MB 的差異性資料。然而，HFS/HFS+ 下你必須完整的重新紀錄一次 10MB。也就是說，你雖然只修改了 1MB 的資料，卻變成需要紀錄兩次 10MB 的資料。這也就是 Time Machine 效能不理想，而且浪費硬盤空間的原因。
其實 HFS/HFS+ 還有許多其他的問題存在，雖然 OSX Leopard 有在 HFS+ 上又動了一些手腳，改良了一些資料結構上的問題，但是，這種有洞補洞，亡羊補牢的作法，根本沒有辦法把 HFS/HFS+ 的問題完全根治。
我曾經在我的部落格當中寫過 Time Machine 這部份的問題。
（http://blog.osx119.com/?p=98）更值得一讀的是 ars Technica 有發表過 Time Machine 的技術分析，也提到了 HFS/HFS+ 的詬病。（http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/14）
在 Leopard 還沒上市前，很多技術人員一直希望 Apple 能採用 ZFS 的原因。畢竟 HFS 算算也都 20 幾年的古董了，HFS+ 也都要十年了，技術上根本就太落後了！所以 Linus Torvalds 所言屬實，這點是 Apple 必須檢討的地方。
題外話，其實 OSX 現在的 GUI 框架方式，早在 NeXT OS 上就已經出現了。雖然經過了幾代的演變，改了很多東西，進化了不少，但是，那個 Finder 的結構框架，還是挺像的。有機會可以看看 NeXT OS 的 GUI 畫面，不難發現 Steve Jobs 真的是把整個 NeXT OS 帶進 Apple。