不過 lenny (5.0.0) 從去年二月到現在也已經過了一年，雖然一直有在更新 (現在是 5.0.4)，但為了穩定性，並不是所有的軟體都有更新。印象中有個計畫是專門解決這個問題的，可以讓你在 stable 使用新版，但不是整個系統都換到 testing 或 unstable。

在印象中跟 “backport” 這個關鍵字有關，翻了以後找到 Debian Backports，看起來就是我要的…

依照「instructions [Debian Backports]」操作，直接把 entry 加到 /etc/apt/sources.list 內，用 apt-get update 更新一次，這時候會出現不認得 public key，不管他直接 apt-get install debian-backports-keyring 就收工了。測過沒問題後，就在「Backports.org worldwide mirror sites」這邊找亞洲區的 mirror site，看起來只有日本有做，改過去再測一次 update，沒問題收工…

由於預設仍然會使用 lenny 內的套件，如果要裝 backport 內的東西，需要用 -t lenny-backports 讓 apt-get 或是 aptitude 知道。

另外，在「Diffs between lenny-backports and squeeze」這邊可以看到 lenny-backports 與 squeeze (目前的 testing) 的差距。

在 FreeBSD 上可以利用 httpready 把一些事情丟到 kernel module 處理：

listen 80 default accept_filter=httpready;

httpready 參數必須設定在有 default 的 listen 之上，而且必須在 default 之後，不然會回報設定錯誤。

server_tokens 也應該關掉，除了 security 理由外，另外一個很簡單的理由是，可以少送 7bytes…：

server_tokens off;

有人曾經建議 Mozilla 直接使用系統的 codec 避開這個問題，但 Mozilla 認為這種作法跟 ActiveX 一樣，直接把系統不安全的部份暴露在 Internet 上，當 codec 有漏洞時就會受到影響。(我覺得專利問題還是比較嚴重)

因為這些原因，Mozilla 選擇內建 Theora 而非使用 H.264。最早支援 video tag 的 Opera 也是選擇 Theora。

Google 與 Apple 手上都有與 H.264 相關的專利可以丟進專利池而取得免費使用權，所以 Google Chrome 以及 Safari 都是支援 H.264。

Update：如同 Azel 在 comment 所講的，Google 沒有專利丟到專利池內，而是購買授權。(參考 AVC/H.264 Licensors 與 AVC/H.264 Licensees 資訊)

除了專利問題外，有些人研究 H.264 與 Theora 在技術上到底哪個比較好，如果兩個差不多的話，沒有必要用 H.264 讓別人綁死。

在 OSNews 的「Comparing Theora to H264」裡講到有三篇測試文章。

最早的是「YouTube / Ogg/Theora comparison」這篇，這篇不是講 H.264，而是 YouTube 使用的 H.263。這篇文章之前有上過 Slashdot，但當時看過以後有個印象而已，因為他用的方法是肉眼，而非科學方法。雖然如此，還是很明顯可以看出來在 500Kbps 以下時 Theora 比 YouTube 的 H.263 好不少。

最近的兩篇分別是「Ogg vs H264 – Round One」以及「Video encoder comparison」，後面這篇是我第一次看到有人用科學方法 SSIM 計算壓縮前後的相似性。不管哪一篇，都可以主觀或客觀的看出來品質上 H.264 大勝 Theora，而壓與解的速度則是反過來。

不過下面的 comment 提到 Theora 目前真正在開發的不在 trunk 內，而是在其他 branch 下，另外 Theora 如果設定 bitrate，會是 CBR mode，品質會比 VBR mode 差。實際要比較每個 codec 最好的情況應該要跑 2-pass。

過幾天應該會有新的 report 出來，到時候再來看差異…

他們討論到 IE 到目前所有版本的 cookie 都不支援 max-age 參數，所以有個避免 MySQL master/slave replication lag 的技巧在 IE 上沒辦法用的很好：當寫入資料時 (例：使用者發表文章)，server 會設定一組 30secs 的 cookie，當 web server 收到這個 cookie 時會用 MySQL master server。

workaround 不難做，本來是只有設定 cookie，現在把把 server timestamp 與 signature (用 HMAC) 都放到 cookie 後就可以了，當 web server 收到後可以驗證並且決定是否要用 master server。

其他的限制可以看一看留個印象，之後遇到時會比較有機會猜到…

Eventual consistency 以 CAP theorem 中的 Consistency 妥協，試著解決 scale 問題，但缺點是 stale read (可能會讀到舊資料)，對要求比較嚴謹的子系統 (像是遊戲內的各種點數，身上帶的金幣之類的) 會很麻煩，而對於要求更嚴謹的系統 (像是商品搶購時的「剩餘數量」) 幾乎無法直接使用。

像是 Colin Percival 曾經解釋他得在 S3 與 SimpleDB 上做不少 workaround：「How Tarsnap uses Amazon Web Services」以確保資料正確性。

AWS SimpleDB 這次提供了新的功能，要求寫入時一定要等到 consistent 才 return，將 consistent 的權限放給上層 application 決定，開發者可以自己拿捏。

DRBD 是一套以 block-level replication 為基礎提昇可靠度的軟體，有時候為了方便解釋，也被稱為 Network RAID1，常搭配 Heartbeat 或是其後繼的 Pacemaker 偵測節點是否還活著，並在必要時自動切換。

由於 DRBD 已經出來很久了，而且又是以 GPLv2 釋出，早期有不少文件介紹如何使用 DRBD 達到 HA，算是一種已經被摸熟的方案。

另外是 FreeBSD 的 HAST Project 到一個階段，被 commit 到 -HEAD 了：「Please welcome HAST – Highly Avalable Storage.」，再加上 block-level replication 會需要 Filesystem 快速恢復的 SUJ (SU+J) 也在一月底放 source code 先讓自願者測試，一口氣補了 HA 領域兩塊重要的缺陷。

不過依照慣例，新東西都不太穩定… 玩玩還可以，如果是要跑 HA 的話等一兩個版本會比較好。

非 Comcast 用戶沒有辦法參與，丟 query 過去會收到：

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 54496
;; flags: qr rd ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

這次並非對等的交換，雙方除了交叉授權外，Amazon 還付了一筆錢給微軟。

不同於之前 Novell 的情況，有不少人猜測 Amazon 會跟微軟簽授權是因為 Amazon 發現他們所使用的某些技術踩到微軟的專利，而且發現難以避免。由於 Amazon 用了許多 open source 軟體與技術，更使得許多人對這個消息感到不愉快…

X-Pad: avoid browser bug

用 Google 找了一些資料後發現是為了 workaround Netscape Navigator 2.x 到 4.0b2 的 bug 而做的：「Why is Apache sending a “X-Pad” header?」。

在 Revision 77941 可以看到這個 commit log，1997 年 4 月的事情…

由於每個帳戶的 Access Key ID + Secret Access Key 就可以存取這個帳戶所有的 S3 檔案，在不同的 project 時分開不同的帳戶會比較理想。但這樣在計費時得分開算，同時帳單也變多。

也許在付費窗口單一化後會規劃非信用卡付款，對於用量非常大的企業應該會有幫助。