Blog活過來了

上個月某一天，正在遠端update我的server的時候，突然ssh斷線，telnet也進不去。完全不知道發生什麼事情了，但是因為爸爸媽媽的電腦上網沒問題，所以也就暫時沒管它。後來嚴重到影響到他們上網了，所以只好請遠在台北家中的爸爸把server reset。
進去一看，發現是 root proc_count過多，結果爆掉了。想想應該只有portmanager會造成這種現象。之前在orion上面也是，portmanager跑 -u 的時候友可能會跑到一半就core dump。看來package management還是個大麻煩.....

最早的時候，FreeBSD 只有 pkg_* 可以用。 pkg_add, pkg_delete，一直到有人寫了 sysutils/portupgrade，日子才變得好過一些。自動track dependancy，自動upgrade tree等等。但是portupgrade一直有幾個問題：
1. ruby dependancy，這樣跟早年perl dependancy是一樣的，都得多裝個 lang pack。不過這一點現在看來，反而是一種好處(後述)
2. 常常會有stale dependancy。比如 p5-Berkeley-DB如果選的是DB44，應該 p5-Berkeley-DB的depending ports會跟著pickup DB44當作他的dependancy，但是事實上卻是每次都抓到原來的DB3當作 dependancy。
3. 速度很慢，所以db format需改成 db4以上，才有顯著的改善。
portmanager一開始就用C來寫，所以performance相當好，所有的速度瓶頸都是在 make -V <$var> 這個步驟。portmanager 也不需要另外開一個 dependancy db，全部都照 /var/db/pkg裡面的內容作判斷。這樣可以解決上面2的問題，因為它的dependancy是依照 installed ports裡面的 +CONTENT 來判斷，而不是照 ports Makefile的來判斷。當然portmanager也不是沒有問題。用C寫的程式常常會有buffer overrun的問題(sigh....our server code)，之前 Mike Schultz就做了好幾次這種修正。這次更是因為 fork 出去的東西太多，造成整個系統出問題。這時使用ruby的好處就出現了，interpreter 式的語言或是 bytecode based的語言在 VM/interpreter的限制(or say 保護?)下，很少可以讓系統整個掛在那邊。所以還是乖乖回到 portupgrade的懷抱，畢竟server遠在數百公里之外，要真的卡住了，也不是幾個小時就可以回去修理的。很可惜的是 Mike 決定不繼續開發portmanager，不然我真的還有很多 bug report要給他咧....