幹壞事是進步最大的原動力
如果想在 Amazon EC2 上跑 XFS，在某些情況會遇到 kernel panic，而這個問題在 lenny (以及之後的版本) 上有比較簡單的解法了：「Debian Lenny and XFS causes kernel panic: Suggested Workaround」，解法是在 mkfs.xfs 時多增加 -l version=1 即可。
另外官方也在下面 reply 了另外一個解法，針對 FC8 kernel 的修正。
然後 Eric Hammond (EC2 上最有名的 Debian AMI 製作者) 說 Ubuntu 也開始在測試 EC2 platform (www.ubuntu.com/ec2)，將會是第三個解法...
如果有在 EC2 上用 EBS 跑 MySQL 的，可以考慮換成 XFS... MySQL 在 XFS 上比起 ext3 好不少。
portmaster 是管理 FreeBSD 套件升級的程式，比起 portupgrade 的主要優點在速度 (這是重點)，配合 portconf 幾乎可以替代 portupgrade。(參考兩年前的「portupgrade、portmaster、portconf」這篇文章)
雖然兩年前就想要拿掉 portupgrade，但當年的 portmaster + portconf 用起來不習慣，直到這幾天為了升級強迫自己學習 portmaster，才試著把每個功能找出來。(速度考量。因為最近忙，實際用 portupgrade 發現完全不能接受)
常用的指令包括：
對 portname 以及他所用到的 port 升級，不要一直詢問「是否要砍掉備份的 package」：
# portmaster -u [portname]
portmaster 會把舊版軟體包成 package 放在 /usr/ports/packages/portmaster-backup，如果不需要可以砍掉。
將 pecl-hash-1.5 用 security/php5-hash 取代：(搬位置)
# portmaster -u -o security/php5-hash pecl-hash-1.5
-o 這個指令與 portupgrade 相同，沒有什麼大問題。
順手後，效率又上升了不少...
不知道是從哪邊傳出 CNAME 不能設到 CNAME 的觀念，剛剛特地找資料，發現可能被「誤解」的地方。
在 RFC 1034 裡因為效率問題「建議」不要 CNAME to CNAME，但也強調這不應該視為錯誤：(5.2.2. Aliases)
Multiple levels of aliases should be avoided due to their lack of efficiency, but should not be signalled as an error.
參考：「Cname of Cname」。
T-Mobile G1 整合了許多 Google 的服務，像是 Gmail、Google Calendar 以及 YouTube。(在 G1 上面三個我最常用的服務)
年前跟老大聚餐時聊到 iPhone 就聊到很多有趣的想法。現在想想，在 G1 上面也可以用...
現在除了不能用打中文外 (KerKerInput 操作上還是不方便)，其他的倒是都還不錯...
前陣子 jQuery 1.3 出來，但問題還不少，除了在 jQuery 官方的 bug tracker 上可以看到外，在 PIXNET 內部測試時有發現一些問題，所以就暫時維持 1.2.6... (IE6 變快不少，所以以，其他的 browser 速度都不錯)
jQuery UI 這陣子在 RC 階段，結果決定要同時維持與 jQuery 1.2.6 與 1.3 的相容性：「jQuery UI 1.7 is the new 1.6」。
jQuery UI 1.6rc6 + 修正會是 jQuery UI 1.7，這個 branch 需要使用 jQuery 1.3 或更新的版本。而 jQuery UI 1.6rc2 + 修正會是 jQuery UI 1.6，讓決定使用 jQuery 1.2.6 的人可以享受到 jQuery UI 的新功能，但這個版本在完成後就沒有打算維護，純粹只是階段性產品，讓大家有更充裕的時間測試 jQuery 1.3+...
懶的自己管機器了，所以把 blog.gslin.org 換到 Media Temple 的 Grid-Service，機器反應速度還蠻快的。
在 Google Blogoscoped 看到的「Load Time of Google Analytics Script」這篇文章，介紹了 Pingdom 的「Google Analytics script loads 97% slower at peak hours – in Europe」這份報告。
文章裡 Pingdom 量測 Google Analytics 的 javascript (urchin.js 這個檔案)，發現在各地區尖峰時間都會變慢，尤其是歐洲會慢將近一倍的時間。在 Pingdom 的分析裡發現歐洲部份的讀取時間與 AMS-IX 提供的流量圖接近。
這個檔案因為有設定一定時間的 expire time (604800 secs，七天)，加上有接近 1/4 的頁面有使用 Google Analytics 的服務 (參考「MAMA: Scripting syntax」這篇文章裡提到的「External script file names」)，我覺得讀取速度不會有太大影響，Google 算是盡人事了。