Home » 2009 » September

Google Docs OCR

在「Google Docs OCR」這邊看到 Google Docs 也開始試著提供 OCR 服務了:「Import Scans or Go Multilingual」,不過剛開始還不穩定,傳了兩次都是 error,應該是因為服務很吃資源,而想要測試的人又多。

以文章作者自己上傳文件測試的結果來看 (英文的文件,他拿 RFC 2616 印出來後掃描的圖檔),有些地方有錯字,不過整體的效果還不錯... 等穩定後再來測試中文文件,有沒有支援中文對我們很重要...

如同作者講的,網路上提供免費 OCR 的服務並不多,如果 Google 決定把這項服務併入 Google Docs 裡的話,一定會打亂現在 OCR 付費的生態...

TI 工程計算機的 RSA private key 被破解

TI 工程機算機的 OS firmware 需要 sign 過才能用,但其中使用的 RSA key 的有效長度只有 512bits,所以被暴力法搞定:「Texas Instruments Signing Keys Broken」。

查了 Wikipedia 上的「RSA Factoring Challenge」,早在 1994 與 1996 年左右,RSA-129 (426bits) 與 RSA-130 (430bits) 就已經被分解成功了,當時比較安全的 RSA 保護會是 1024bits (現在一般都建議 2048bits 了)。

在「Comparison of Texas Instruments graphing calculators」可以看到很多被破解出來的型號是在這之後 (甚至在 21 世紀推出的型號) 所推出的版本,於是在 2009 的電腦,透過 BOINC,一個禮拜內就把這些 private key 算出來:「All TI Signing Keys Factored」。

TI 用 DMCA 要求下架,不過在很多美國境外的網站上都找得到這些 private key 了,我猜這幾台會熱賣起來... (因為可以自己刷 OS 韌體)

FreeBSD 8.0-RC1 釋出

在「FreeBSD 8.0-RC1 available」這邊提到 8.0-RC1 出來了,看起來是第一個 kernel 沒有一堆 debug info 的版本,要測效能這時候跳下去測會比 8.0-BETA4 準確,順便把之前一直在測試的 8.0-BETA4 升級到 8.0-RC1... (測 NFS 的穩定度)

用台灣的前兩個 mirror site 安裝,發現慢到爆炸 (ftp.tw.freebsd.org 與 ftp2.tw.freebsd.org,分別是交大國高),實在沒時間找原因,暫時先跑去 ftp.jp.freebsd.org 抓...

事後看了 traceroute 與一些紀錄,交大的部份大概沒救,應該是奇怪的 filter 或是 routing 亂跑之類問題造成。國高因為只能看單邊 (TFN 端),看不出原因。

再來就是文章的這段,看了讓人笑得蠻開心的:

How many RC's we have will depend on how well 8.0-RC1 does. At the moment only one more RC is on the schedule but odds are fairly high we will wind up inserting at least one more RC. Between BETA4 and RC1 a lot of work has gone into IPv6 issues as well as many other issues that have been brought up from the public testing. And a patch set was committed by the people who handle porting ZFS to FreeBSD that they felt makes ZFS production-ready.

我的解讀是:

這之後到底還會出多少 RC,要看這次 release 的 8.0-RC1 表現的如何。照表操課最少還有一次 RC,不過因為從 8.0-BETA4 到 8.0-RC1 我們又翻動太多東西 (IPv6 與 ZFS),沒有意外的話應該會有東西爛掉,所以應該還會再多一個 RC。

至於 8.0 的 ZFSv13 是否 stable,我還是很懷疑... 備份時跑大量的 rsync 時,有一些 rsync process 會卡死 (process 砍不掉)。另外有 kernel level memory leak,不過這點可以用每天重開機來解決... (順便解決前面的卡死問題)

Google Chrome Frame - 在 IE 裡面使用 Chrome

TechCrunch 看到 Google 推出「Google Chrome Frame」,將 Chrome 嵌到 IE 裡面:「Google Has A Solution For Internet Explorer: Turn It Into Chrome」,這個軟體的作法有種 IETab 的感覺...

使用者裝了 Google Chrome Frame 後,並不會使得所有的頁面都用 Webkit Engine 呈現,而是網頁製作人必須要指定「我的頁面可以用 Google Chrome Frame 顯示」才會執行:(如果是 XHTML 的話要記得加上 slash)

<meta http-equiv="X-UA-Compatible" content="chrome=1">

另外還可以利用 Google 提供的 API,可以偵測使用者是不是 IE 而且沒有裝 Google Chrome Frame,如果沒有的話,可以提示使用者安裝...

裝好後,可以在 IE 裡面用 cf:http://... 強制使用 Google Chrome Frame 測試,最明顯的改善就是字體與 input 框 (當 focus 上去時邊框會改變顏色),可以測試看看。

除此之外,裝了以後發現 Google Gears 也被裝進去了...

最後留個在 IE7 + Google Chrome Frame 的 Acid3 畫面吧 XD

用 Facebook 上的公開資料猜測性向

Slashdot 上看到兩位 MIT 的學生發展一套程式 (這個計畫被稱為「Gaydar Project」),試著用 Facebook 上公開的資料來研判「是否為同性戀」:「MIT Project "Gaydar" Shakes Privacy Assumpitons」,除此之外,參與的團體、喜愛的音樂也都能夠拿來分析各種性向。

這個計畫應該會使得網路上的隱私問題又被拿出來批判一番... 一定會有鄉愿的人跳出來批評「不應該做這類研究」。

這類問題在於,資料是公開的,方法也是人發展出來的,就算在全美禁止,也會有學者在其他國家發展出來。真正想要解決問題還是得從根本解決,也就是「個人資料有沒有辦法保護的更好」,現有的保護程度 (更精確的說,至少 Facebook 現有的保護程度) 可以讓研究人員取得足夠資料,表示不夠用。

可以預見之後政府單位 (尤其是教育單位) 會宣導「不要在網路上留下個人資料」試著卸責,但卻沒有成效。

磁碟出錯機率與 RAID

在「RAID's Days May Be Numbered」這篇文章裡面提到使用 RAID6 的好處。

不過,比較有趣的地方是在 2009 年現在的「Hard Error Rate in Bits」數據,說明消費性 SATA 硬碟、企業級 SATA 硬碟、SAS/FC 硬碟的差異。這個數字也是在規劃 RAID 時的重要依據。

由於用料與製作過程的差異造成 error rate 不同,在重視資料的場合裡,大檔案會用企業級 SATA 硬碟跑 RAID6,而資料庫會用 SAS/FC 硬碟跑 RAID1+0,而且都不會串太多顆。

Microsoft Ajax CDN

微軟放出了 Microsoft Ajax CDN,將 jQuery 1.3.2 與微軟自己發展的 JavaScript library 放上 CDN:「Microsoft Ajax CDN」。

並沒有像 Google 那樣自己在全球建立 CDN,而是採用 Akamai 的服務,所以速度上相當快。不過缺點是不支援 HTTPS,不像 Google 的 https://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js 有合法的 SSL Certification。

ToS 也是相當長,而且是 docx 格式... 大致上都還蠻普通的。

MySQL 的調校 (軟硬體、版本、設定)

把一些關於 MySQL 的資料整理一下。

初期的 MySQL 隨便跑沒關係,備份的部份記得要把 binlog 也一起備份起來,用 gzip 壓過後 (不使用 bzip2 或是高壓縮率參數,是因為考量解壓縮速度;另外推薦用 Parallel gzip 壓縮,速度比較快) 再用 openssl 加密丟到 Amazon S3 上。

成長後,買獨立伺服器要一次買兩台跑 HA,每台分別是:

  • CPU 要考量 SQL query 的方式,如果打算在 MySQL 做很多事情 (i.e. JOIN),CPU 要選高階的;如果大多都是 simple query,則以 C/P 值高的 CPU 優先:兩顆四核心 CPU 算是現在比較划算的硬體。不管哪一種,選低電壓的,像是 Intel Xeon L5408 或是 Intel Xeon L5520,因為硬碟蠻熱的,要減少熱量以免伺服器容易當掉。
  • 記憶體愈多愈好,64GB 算是還蠻基本的。
  • 硬碟選轉速快的 15krpm SAS,挑大一點的硬碟 (以現在的市場就是 300GB) 省得以後空間不夠要搬動。最好是硬體 RAID1+0,依照應用決定單台 database 要多大,如果預定八顆的話可以買 2U 來塞。

軟體的部份:

  • 一定要跑 Linux x86-64 版本,挑大的 distribution 以免遇到問題卻無法解決。我自己還蠻偏好用 Debian。不論是 Debian 還是其他 distribution,儘量跟穩定的 branch,遇到需要升級時的問題會比較少,像是 Debian Lenny
  • 如果要跑 DRBD,先在兩台上面設定好 Heartbeat + DRBD。如果是跑 MMM 的話就設定 MMM,比較需要注意的是 MMM 的版本,參考「MySQL MMM 的情況」。
  • Filesystem 跑 XFS,很多人在上面跑很久了,經過時間考驗的 Filesystem,跑起 MySQL InnoDB 的效率還不錯。
  • MySQL 跑 Percona 的 5.0 標準版本 (非 highperf 版),穩定性還不錯。如果預期到資料量很大的時候會是 I/O bound,可以考慮 Percona 的 5.1 版本,並且開啟 InnoDB Plugin 壓縮的功能。
  • 跑監控程式,把系統的狀態記錄下來。可以是 MuninCacti 或是 nagios,資料對於瓶頸分析很重要。

my.cnf 設定的部份要花不少功夫,除了一般常見的設定外 (這部份網路上很多文件),有些在站台比較大時會發生的問題要注意:

  • back_log 要開大,因為站台大的時候通常不會用 pconnect (每個 web server 都掛著 64 個連線,當有十台 web server 就佔用 640 個連線),而是用 connect,在每次做完事情就斷線,配合 memcached 降低 MySQL 的需求。不過在量夠大的時候,還是會遇到預設的 back_log 不夠。Smugmug 的 CEO 在「Great things afoot in the MySQL community」有提到吃過這個值的虧。
  • max_allowed_packet 設大一點,避免比較大的 INSERT 或是 UPDATE 造成錯誤。通常這是設計上的問題,應該要避免在 MySQL 裡放 blob 資料,不過偶而還是會需要...
  • max_connect_errors 設 4294967295,可以避免當 client (像是 php) 發生太多錯誤時被 block 住。
  • innodb_adaptive_checkpoint 要打開,可以避免在 flush dirty pages 的時候產生 slow query。MySQL 官方的版本沒有這個參數,而這個參數也是為什麼要用 Percona 版本之一。效果可以參考「Adaptive checkpointing」這篇文章。

Election Hash

大約是六七月的時候在 F5DevCentral 上面看到 Election Hash 這個分配方法:「Hash Load Balancing and Persistence on BIG-IP LTM」。

演算法的部份在 F5 的文章裡寫得很清楚了,這邊就不重複再說明。

Consistent Hashing 需要一個 shared storage 放 ring 資料,但這個方法不需要,另外一方面,這個方法寫起來比較簡單,而且 query 會打散的很平均,不像 Consistent Hashing 需要用 virtual node 從機率上平均。

會用 Election Hash 一個主要的原因是 iRuleTcl 語法,簡單的演算法寫起來就已經很長了,如果再複雜下去... XD

比較明顯的缺點在計算的量:每次 query 進來都要跟所有的 node 計算 hash value,在 node 多的時候應該會感覺到速度下降。不過目前也只有用在 cache server 的 VIP 上以提高 hit rate,後面的機器數量都不多,所以看起來還 okay...

Archives