幹壞事是進步最大的原動力
前陣子提到了「用 C 改寫後的 Gearman」，在當時還是 0.1 版，現在已經 0.2 版了。花了一些時間把他 submit 到 ports tree 裡面，現在可以在 ports 裡的 devel/gearmand 裝起來，然後在 /etc/rc.conf 裡設定：
gearmand_enable="YES"
裝好後預設是聽 port 4730 (IANA 配的位置)，並打開 verbose 選項，也就是：
gearmand_flags="-p 4730 -v"
如果要用舊的 port (7003)，而且也不想要開 verbose：
gearmand_flags="-p 7003"
這樣就可以了。
環境是單顆 E5405 的機器，上面的作業系統是 FreeBSD 7.1，應用程式的部份是 apache 2.2 (worker) + mod_fastcgi 2.4.6 + PHP 5.2.8 + APC 3.0.19。
由於前陣子發現 PHP 在 MP 架構下效能不太好，偶而會有一堆 php-cgi 卡住，用 top 會發現卡在 "lockf" 這個狀態，這時候前端的 L4 switch 會看到 500 Internal Server Error 而把這台機器暫時離線。等到 php-cgi 慢慢消化完，前端的 L4 switch 又會抓到 200。
在 php-cgi 卡住的狀況下試著用 gdb 找原因，當時 backtrace 發現是卡在 APC 裡的 lockf，所以就有一些想法，等有空閒的時候測試。
第一個想法是把 APC 的 lockf (fcntl) 改用 IPC semaphore，這個在 ports 可以調整。重新編完後發現 php-cgi 跑不起來，後來試出來，需要同時打開 mmap support 與 IPC semaphore。
第一張是 webfront-7，跑 mmap + semaphore。第二張是 webfront-8，保持原來的 shm + fcntl (lockf)：
效能有「好一點」，但很難觀察出來，實際再加上 webfront-{9,10} 比較後 (都是完全同型的伺服器)，看起來 webfront-7 的效能是最好的，所以得觀察當爆量時是否會卡 lockf。
很久之前就在關注的服務，與 Amazon Web Services 的 S3 + CloudFront 是直接競爭關係。
在很早前就註冊，但一直因為帳號問題而沒測試，當時以為是系統忙碌，懶得寫信去問。這幾天想趁著過年的時候測，發現帳戶還是有問題，所以昨天請他們處理，今天帳號就正常了...
Mosso CloudFiles 的背後是 Rackspace，是一個與 Amazon S3 性質相同的檔案存儲服務，不過與 Amazon S3 不同的是，他的 HTTP 下載部份一定要透過 CDN，不像 Amazon S3 可以到 original server 抓取。
Mosso CloudFiles 使用的 CDN 是 Limelight Networks，這是全世界第二大 CDN，也是 YouTube 在使用 Google 的網路前使用的 CDN。他目前的價錢從 USD$0.22/GB 開始計算，與 Amazon CloudFront 的 Japan Edge 同一個等級，但 Limelight Networks 在 CDN 這塊的功夫比起 Amazon 真的強很多，像是 HiNet 的使用者會導到到美西的伺服器，而非香港的伺服器 (因為 HiNet 到香港的伺服器會走到北美)。
Mosso CloudFiles 的價錢頁面在「Pricing / Scaling」。Amazon CloudFront 的價錢則是在「Pricing」這頁。
比較重要的是 CloudFiles CDN 的 GET request 本身是不算錢的，拿來放 CSS 與 JavaScript 之類的小檔案似乎相當不錯？
除了官方提供了一些 API 外 (以及一些官方提供的 dev library，包括 Java、PHP、Python、C#)，Perl 的社群也寫了 CPAN module：Net-Mosso-CloudFiles，所以拿來跑 routine job (備份之類的) 應該沒有大問題。
價位與 AWS 都差不多，以儲存空間及頻寬計費，目前 Inbound bandwidth (從外面流入 CloudFiles) 有優惠，可以看一下。
Update：發現兩個大缺點，使得 CloudFiles 沒那麼吸引人了：
Update：okay，直接問還是比較有效率的。第一個問題的答案頗糟糕：
@gslin There is a built in TTL - it can be changed vie the API.
是可以設短一點，但實在不太舒服...
CAPTCHA 廣泛的被用在阻擋機器人，一般是給你一張圖片，要求你輸入圖片的字。為了避免用 OCR 破解，CAPTCHA 通常會有各種變化，讓程式難以破解。
但 Megaupload 的 CAPTCHA 的變化很簡單，像這樣：
於是就有人用 Firefox + Greasemonkey，在純 JavaScript 的環境下以類神經網路破 Megaupload 的 CAPTCHA：「Megaupload auto-fill captcha」。
John Resig 甚至寫了一篇文章分析這隻 Greasemonkey script 的程式碼：「OCR and Neural Nets in JavaScript」，從利用 getImageData 取得圖片內容、轉灰階、切字、去雜訊，到最後計算 Megaupload 的 CAPTCHA...
剛好在 Slashdot 上看到「Building a Better CAPTCHA」也在討論用 CAPTCHA 是否能解決問題。(comment 才是重點)
星期五晚上去天瓏一趟，把 ppk 寫的《ppk on JavaScript》中文版抱回家看，可以趁著年假沒有網路時翻閱。
英文版是在 2006 年出版的，書評可以參考 othree 寫的「ppk on javascript 書評」，中文版在 2008/8 出版，由 Taobao UED 翻譯。
在講 JavaScript 的歷史時 ppk 提到：
在我寫這本書的時候，Ajax 的熱潮仍然席捲全球。但是我相信他最終會像 DHTML 那樣結束：人們會完全對它失去興趣，而它將會原形畢露，只是少量 JavaScript 和大量的空話，雖然我不知道這會在何時發生。
JavaScript 將回歸瘦時代，那時它的用途將再次被重定義，大型的解決方案將被精巧簡單的腳本所取代。
前面的趨勢似乎不會來臨，Ajax 被大幅證明對於操作介面的幫助，甚至還推動瀏覽器的升級。後面提到的事情，jQuery 這類 JavaScript Library 似乎符合 ppk 的想法。(jQuery UI 是另外一回事了...)
2009 年看 2006 年的人對於未來 (當時的未來) 的猜測還蠻有趣的。
這篇說的方法在 Debian 可能也一樣，不過暫時沒有打算在有 Debian 的機器上測試。
關於 Ubuntu 的修改，你可以參考「Java - Community Ubuntu Documentation」這篇，我在下面提到的方式會透過 update-alternatives 修改。
裝完 Sun 的 Java 後發現還是跑 GNU 的版本，看了 link 結構後猜大概會跟「Ubuntu / Debian 快速修改預設編輯器(nano -> vim)」這篇的方法一樣：
lrwxrwxrwx 1 root root 22 2008-10-27 01:38 java -> /etc/alternatives/java*
所以修改方式是用 root 跑：
# update-alternatives --config java
同理，如果要把 compiler (javac) 也換成 Sun 的版本，用：
# update-alternatives --config javac
就可以了。用 -version 可以驗證：
$ java -version java version "1.6.0_10" Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode) $ javac -version javac 1.6.0_10
John Resig 寫了篇 jQuery 1.3.1 的細節 (順便公告 jQuery 1.3.1 出版了)：「jQuery 1.3.1 Released」。
主要包括：
1.3.1 修掉的 bug 在「{30} jQuery 1.3.1 Closed Bugs」這裡可以看到。(裡面有一個 enhancement，不太重要？)
FreeBSD 上跑 Apache 2.2 worker 的方法在「apache22 (worker) + mod_fastcgi + php5-fcgi」這篇寫過了，同樣的架構在 Debian 上跑卻發現比 prefork 還吃記憶體，花了一些時間找，發現是預設的 Stack 太大造成的，所以：
<IfModule mpm_worker_module>
ThreadStackSize 65536
ThreadLimit 256
StartServers 1
MaxClients 256
MinSpareThreads 1
MaxSpareThreads 256
ThreadsPerChild 256
MaxRequestsPerChild 0
</IfModule>
加了 ThreadStackSize 這個設定後，每個 thread 的 stack 就會比較小了 (預設超過 1MB，不記得多少了)，這個方式跑了一個月後還蠻正常的。
jQuery 1.3 正式版照著預定，在 1/14 放出來了：「jQuery 1.3 and the jQuery Foundation」。1.3 的 release note 可以在「Release:jQuery 1.3」這邊找到。
速度改善很多，主要是 "HTML Injection Rewrite" 的部份改寫後的效果最好。(Selector 的部份還好，本來就很快)
Google AJAX Libraries API 上也有了：http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js，要使用的人可以自己設定，不過文件還沒更新。
Update：John Resig 在 Twitter 上提到 1.3 有些 bug，所以下個禮拜可能會出 1.3.1。
在 37signals 上的「The bullshit of outage language」這篇提到當機時 (outage) 這三個詞彙毫無誠意：
然後第一個 comment 的地方，有人找到之前 37signals 因為 Rackspace 爛掉造成服務中斷時的道歉公告「Downtime notice」：
We deeply apologize for any inconveniences this may have caused and will work hard to make sure we reduce the likelihood of this happening again.
(狂噴淚)