幹壞事是進步最大的原動力
因為連上 BBS 還是透過 BIG5 比較方便，所以現在會在同一台機器上掛 BIG5 的 screen 與 UTF-8 的 screen。
首先是修改主機的 /etc/ssh/sshd_config，增加 AcceptEnv LANG，表示 server 會接受 client 所送出的 LANG 環境變數，然後在 PuTTY 的設定裡將 LANG 設為 zh_TW.Big5 或是 en_US.UTF-8 (或是 zh_TW.UTF-8)：
登入後 LANG 變數就會被帶進系統內。
然後，vim 會判斷 locale 而決定 encoding 及 termencoding，所以本來寫死的部份都要拿掉。
這樣在 BIG5 環境下可以連上 BBS，用 vim 編輯一些資料...
依照 http://update.freebsd.org/，7.1-PRERELEASE 並不在升級範圍內，所以會出現像這樣的訊息：
$ sudo freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching public key from update2.FreeBSD.org... failed.
Fetching public key from update1.FreeBSD.org... failed.
No mirrors remaining, giving up.
由於 freebsd-update 是 shell script (有很多 undocument variable 可以調整)，依照「"freebsd-update fetch", fetching public key failed.」這篇的點子，有個邪惡的方法可以拐 freebsd-update，讓他認為系統是 7.1-BETA：
env UNAME_r=7.1-BETA freebsd-update upgrade -r 7.1
這個方法可以用看看... 當然，這個方法一定會有一堆問題，如果對 FreeBSD 不熟的人應該會吃鱉 XDDD
在「Progress with clang」這篇看到，由於最近有人將 FreeBSD source 視為一個超大的 test case，依照 FreeBSD compile 出來的結果不斷修正 clang 的 bug，並且補上缺少的功能，使得由 FreeBSD 衍生出來的 DragonFly BSD 也受益...
現在可以用 clang 編 GENERIC kernel 以及 buildworld 了 (只需要一個 patch)。這陣子 clang 的聲勢愈來愈大了...
Amazon EC2 推出「Reserved Instances」費率，以最小的 instance 為例，你先付了 USD$325，他把 USD$0.1/hour 的機器費用降到 USD$0.03/hour (三折)。
基本上與手機的「月租不可抵」型意思是一樣的，只是他是年約。
假設以 365 天都租用最小的 instance 計算，本來是 USD$876，現在只要 USD$587.8，大約是 33% 的 discount。原來的計價方式與 Reserved Instances 的交錯點在 193.45 天，換句話說，要超過半年多才會比較划算，對一般人應該是沒有什麼影響。
上面一篇「MySQL HA」其實是要提 Mark Callaghan 所寫的「Global transaction IDs are hot」這篇文章。
在三種架構下，DRBD + Heartbeat 的系統要加掛 slave 是最容易的，因為 master server 雖然跳動，但 replication 位置不會變。
在 Master-Master 架構下，由於兩台 master 都有自己的 binlog，會使得 master 跳動時 slave 產生問題，也就是在 Mark Callaghan 文章裡所寫的三種解法 "switch and hope"、"check and lose"、"check and fix"。
這三種解法都並沒有很完滿的解決問題 (第三種解法雖然看起來有 "fix"，但是透過工人智慧手動解決)。
一種方法是引入 Global transactions IDs，這是由 Google 提出的 patch：「MySQL Hierarchical Replication & Global Group IDs」，對 binlog 每筆 transaction 都加上一組 64bits 且遞增的數字，這樣 slave 就不會受到 master 切換而產生 replication err。
先記錄下來，之後很有可能會透過 Google 又找到自己寫的文章...
Update：看到「High Availability for MySQL: Considering the Options」這篇文章，要如何做 HA。
MySQL 有幾種不同的方法實做 High Availability 架構：
這三種方法各有不同的缺點，舉例來說：
DELETE FROM table1;，以及在 db2 下 INSERT INTO table1 SET col1=1;，有可能最後在 db1 上有資料，但在 db2 上沒有資料)，這點可以用把寫入固定到某一台而避免，但由於也是 replication 類的架構，也會遇到 Master-Slave Replication 所敘述的問題。由於資料的正確性會比其他的因素重要，現在我還是偏好用 DRBD + Heartbeat。因 query 的特性而不會有 query dependency 問題的系統才會用 Master-Master。
「5 Minute DBA – Database Server Hardware Selection」講了一些幫資料庫選擇硬體的方式，其實是偏向 MySQL...
簡單的說，CPU 超過 8 CPU 其實意義不大，不需要買 4*4core 或是 4*6core，因為 MySQL 目前無法利用到。
記憶體愈大愈好，記憶體現在便宜許多，如果有 I/O bound 的問題，除了改寫程式外，直接把記憶體加到 32GB 或是 64GB 通常是最划算的方法。
硬碟愈快愈好，有 Hardware RAID10 (要有電池) 會比軟體的 RAID10 好，不過這主要看需求，如果是 CPU bound 的應用，說不定 SATA 硬碟就夠用？
網卡請務必用 GigabitEthernet，最好是 bounding/trunking，除了增加 thoughput 外，也可以當作 redundant link。然後作業系統一定要選 64bits，不然會受限於記憶體可定址空間。
這實在太令人震驚了，FFmpeg 居然釋出 0.5 版 XDDDD
雖然很久沒有 release 新版，但其實 mailing list 上相當活躍，而且更新的速度也都蠻快的。我以為 developer 都已經很習慣叫大家用 Subversion/Git 拉回來編了... XD
在 FFmpeg 的首頁上有放一份簡短的 feature list，這邊就不列了。
要挑什麼 CDN 是依照需求而決定，我會談的是台灣的情況。
在台灣有「用戶」的 ISP 中，HiNet 與 TANet 的出國線路狀態是最差的，其他 ISP 的情況會好很多，所以測試的重點要放在這兩個 ISP。
以影音來說，由於傳輸時間普遍會大於一秒，重點在於 bandwidth 而非 latency。所以到台灣抓與香港、日本，甚至到美國抓其實都 okay，只要 thoughtput 夠高就可以。以 1M 高畫質的影片換算，有穩定 150KB/sec 的速度其實就很順，如果是 600K 或是更低，有穩定的 100KB/sec 以上就 okay。
如果是 css/javascript，因為檔案很小，latency 就變得很重要。可以從台灣本地提供檔案通常是最好的 (<10ms)，或是從日本、香港 (~20ms 到 30ms) 提供，如果 CDN 業者可以幫忙 gzip 會更好 (因為他們會處理 IE6 的一卡車問題)。
如果檔案是屬於下載性質，速度其實不是重點，重點在於成本的話，有些 CDN 業者有提供「經濟型網路」，通常是用北美較便宜的點提供下載。有一定的 commit 時會比 Amazon S3 的 USD$0.17/GB 便宜。
除此之外，會因為不同的性質，要考慮的還很多...
前三大 CDN 服務提供者：
其中 PIXNET 用的 Panther Express 前陣子被 CDNetworks 收購。
另外，很熱門的：
Amazon CloudFront 有公開的價錢，Akamai 與 Limelight 也有可以參考的價錢：(只是參考用)
其中 Akamai 國內有代理商 (併力科技)。
另外還有一些可以參考 Wikipedia 上的表。