幹壞事是進步最大的原動力
Update：原作者拿到硬碟後測試了一天，發現寫入速度不盡理想：24 Hours with an SSD and MySQL。
SSD 硬碟應該要列入耗材...
國外有一些先驅已經在測試把 MySQL 的 data 丟上去跑：Thoughts on SSD and MySQL 5.1，這篇裡建議把 sync_binlog 與 innodb_flush_log_at_trx_commit 保留預設打開的狀態 (用 InnoDB 時，如果為了效率會把這兩個都關掉，尤其是後者，有寫入動作時的速度 (INSERT/UPDATE/DELETE) 會差十倍到三十倍)，不過我覺得為了減少 I/O 還是要開。另外在 OS Filesystem 層的參數也要注意。
jQuery 的大魔頭 John Resig 在他的 blog 上討論了各瀏覽器對 Sub-Pixel 的處理方式：Sub-Pixel Problems in CSS。
在他文章裡，他產生了一個 50px 的 div，裡面包著四個 div，設定寬度為 "25%"，然後丟到 Opera 9、Safari 3、IE 6、IE 7、Firefox 3，以及 Firefox 2 裡測試。另外用 Javascript 去抓 DOM 裡面的寬度。這個問題也可以解釋為什麼某些站台的 Navigation Bar 在不同的瀏覽器下會有奇怪的「殘影」。
FreeBSD 7.0 看起來會在二月放出，似乎會有很多人想要上 ZFS 測試，不過我們自己拿 FreeBSD ZFS 在 RAID 上的穩定度其實還不太夠，另外效率上也不太讓人滿意...
有台 12 顆硬碟的機器，上面是跑 amd64 1GB 記憶體 (目前應該是 4GB 了，下面測試時是 1GB)，ZFS 的架構是前六顆硬碟跑一組 RAIDZ1，後六顆也跑一組。常常跑到 out of kernel memory，加到 4GB 後還是一樣，要改動開機參數，換句話說這部份還沒有寫的很傻瓜... 效率上，在刻意關掉 atime 以 "FTP" 測試 Random Read 的速度卡在 I/O，非常慘的數字：10MBytes/sec。
另外最近剛好看到 Joyent's weblog 上提到他們在 ZFS 踩到大地雷：Bingodisk and Strongspace: What Happened?。(不過他們跑的好像是 OpenSolaris)
我個人覺得，目前拿 ZFS 跑 RAID 的 Code Quality 還要再加強，不過對於一般個人用，拿來打 snapshot 應該是沒什麼問題，我們在 Pixnet 是拿 ZFS 放 log，因為可以開 filesystem gzip，這樣就不用每天跑 cron 執行壓縮程式...
這陣子跑機房發現 IBM R60 真的太重，於是決定把 X31 修好帶著跑，修起來其實蠻快的，星期五晚上送修，星期一就打電話來報價，然後回家把 OS 裝好後開始用，現在看起來狀況還不錯...
我有習慣把 Driver 收到 del.icio.us 上，所以重灌的時候只要把網路卡的 Driver 先裝起來跑一次 Windows Update 後，把還沒裝進去的部份裝好就可以了：gslin's bookmarks tagged with "x31" on del.icio.us。
至於資料的部份，我大多數都是放在網路上，大多數都是 PuTTY 連出去做事，所以也不太需要再處理 :)
微軟以「安全」理由打算在 2/12 時強迫使用者升級至 IE7，如果不想要升級的使用者必須手動設定。
對於 IE6 only 的網站來說，這當然不是什麼好消息。微軟的這項行為等於是強迫他們要處理 IE7 相容性問題。對於使用者來說，在所有的網站都必須讓 IE6 可以正常運作下，用 IE6 的問題反而會比較小。
但對於網頁開發者來說，能夠僅快把 IE6 的市佔率壓低到可以忽略的程度，功德無量...
累積太久沒寫，有些議題剛好可以合併起來看...
第一個想到的是 MySQL AB 被 Sun 買下，以及在 Slashdot 上看到有人認為 Google 的 MapReduce 成功是 Computer Science 界的一大退步 (MapReduce — a Major Step Backwards?)。
把時間點再往前，拉到 Oracle 買下 Innobase Oy 及 Sleepycat Software (Berkeley DB) 兩家公司時一般的反應 (分別是 2005 年十月、2006 二月)，以及買下後的進展...
Oracle 買下 Sleepycat Software 後推出的 Berkeley DB 4.5 多了 Replication 的功能，並且在 Berkeley DB 4.6 對穩定性及大幅度修正。InnoDB 則是不斷的改進穩定度及效率，仍然是目前 MySQL 裡最常被使用的 Transactional Engine。以現在看起來，其實 Oracle 並沒有打算要以這個手段打擊 MySQL。
話題回到 Slashdot 那篇 MapReduce，其實在 comment 有人講得很清楚了：簡單的東西並沒有什麼不好，重點在於能不能解決問題。如果能用簡單的方法解決問題，就不要拿複雜的方法解決，25 年前就發展出的技術並沒有什麼不好。
另外我提一下，最近寫過後才發現 Berkeley DB 其實相當好用 (支援 Transactional Operation 及 Replication)，沒人用的原因是 PHP/Perl/Python/Ruby 上的 Library 都沒有把實做所有的功能，目前只有標準的 dbm operation 而已。換句話說，如果你要用這些好用的 Operation 得自己刻 C/C++/Java。由於開發上的問題，很多人寧可用 MySQL 放...
由於 Berkeley DB 看起來很棒 (傳言 Bloglines 與 Google 的使用者資料都是用 Berkeley DB 為底層架起來的)，初期的目標是希望有個 Reliable DBM-style Database，類似 Amazon SimpleDB 的軟體放使用者資料，透過 TCP connection 與 PHP 端溝通...
大約半年前寫的「使用浮水印取代 DRM」看到音樂產業決定要使用了 (Digital Watermarks to Replace DRM)，但是有幾個問題要考慮：
在李怡志寫完「拿Wikipedia條目當企業網站的一個範例」之後，我就在猜到底多久會被快速刪除 XD
查了一下刪除紀錄 (透過「編輯本頁」看)，是 Shizhao 刪的。
其實反過來這樣想，因為你根本不知道誰去買 Google AdWords 廣告，所以你可以故意幫一些名氣不夠大的人物、團體買 Google AdWords 廣告，指到 Wikipedia 上，然後讓人爆破後被快速刪除。
而相同的，你也可以自己買 Google AdWords 指到 Wikipedia 的頁面上，但是在 Wikipedia 上辯稱跟你沒有關係。
Update：應該是 AdWords。
Firefox 3 支援了 W3C 所制定的 Cross-Site XMLHttpRequest：Cross-Site XMLHttpRequest。
從 John Resig 的說明文件可以看到 client side 不需要修改任何程式碼，而 server side 只需要多送一組 Access-Control 的 header 就可以了。想了一下，似乎沒有額外的安全性問題。
不過要等到能廣泛使用至少要再過個兩年... (IE8？)