Google 將發現安全問題的獎勵延伸到 Open Source 專案上...

Slashdot 上看到 Google 將發現安全問題的獎勵從自家產品延伸到 Open Source 專案上:「Google Offers Cash For Security Fixes To Linux and Other FOSS Projects」。

官方的公告在「Going beyond vulnerability rewards」,規則則是在「Patch Rewards – Application Security – Google」。

初期限制在這些專案上:(直接複製過來)

  • Core infrastructure network services: OpenSSH, BIND, ISC DHCP
  • Core infrastructure image parsers: libjpeg, libjpeg-turbo, libpng, giflib
  • Open-source foundations of Google Chrome: Chromium, Blink
  • Other high-impact libraries: OpenSSL, zlib
  • Security-critical, commonly used components of the Linux kernel (including KVM)

獎勵金額從 USD$500 到 USD$3133.7,這邊的 31337 應該是出自「Leet」吧...

這算是一種回饋社群的方式...

Facebook 的 InnoDB patch 讓 table scan 速度變快...

Facebook 的 Database Engineering team 實作了 patch,讓 InnoDB 在 table scan 的速度大幅提昇:「Making full table scan 10x faster in InnoDB」。

第一個 patch 叫做 Logical Readahead。第二個 patch 是針對 async i/o 的改善 (Submitting multiple async I/O requests at once)。

引用文章內的幾段話就知道這幾個 patch 的功力了:

Logical backup size is much smaller. 3x-10x size difference is not uncommon.

備份出來的資料會變小,而且宣稱 1/3 到 1/10 不是罕見情況... -_-

With logical readahead, our full table scan speed improved 9~10 times than before under usual production workloads. Under heavy production workloads, full table scan speed became 15~20 times faster.

然後 table scan 的速度會快非常多... 10 倍?如果是平常就很操的 database 會更明顯?

如果這幾個 patch 如果沒有什麼問題,可以預期會被 merge 到 PerconaMariaDB,至於 Oracle 官方的 source tree... 有的話當然很好,沒有的話也很正常?

結果 Vim 7.3 出 patch level 1000 了...

前情提要:「Vim 7.4 準備中...」,本來以為會在 1000 出現前出 Vim 7.4。

結果剛剛在 Twitter 上看到「http://ftp.vim.org/pub/vim/patches/7.3/7.3.1000」出現,這是哪招... XD

Bram Moolenaar 該不會自暴自棄決定等 9999 的時候再出 Vim 7.4 吧... XD

維基百科英文版與德文版的資料庫 (條目最多的兩個語言) 從 MySQL 轉移到 MariaDB 了...

維基百科官方宣佈兩個條目最多的資料庫 (英文與德文) 已經從 MySQL (有 FB patch 的版本) 轉移到 MariaDB 5.5 了:「Wikipedia Adopts MariaDB」。

維基百科的資料庫從 MySQL 4.0 升級到 MySQL 5.1 時花了不少功夫轉換 (可以想像出來,這兩個版本的差距...),然後這次再到這次的 MariaDB 5.5 就輕鬆不少。

在文章內有提到因為維基百科是 read-heavy site,大多數前端的負荷都在 squid 層擋下來,實際到後端的量則是再透過 Redismemcached 打散負荷。不過即使做了這麼多層 cache,英文版資料庫在尖峰時間還是有 50k qps 的量在跑。

尖峰時間這 50k qps 的量有 80% (也就是 40k qps) 是打散到兩台不同地點的 slave 上,平均的 query response time 是 0.2ms,95% 則是 50ms (好高),其他的 20% 是寫入 master 需求,或是因寫入 master 時需要一致性 (也就是要避免 replication lag 造成的問題)。

這次升級到 MariaDB 5.5.30 是先準備一台新機器,然後在 load balancer 上換掉其中一台 slave (先建後拆),如果 MariaDB 真的有問題也可以馬上 rollback 回來。另外用 pt-query-digest 取樣分析 query 的狀況。

這是成果:

For our most common query type, 95th percentile times over an 8-hour period dropped from 56ms to 43ms and the average from 15.4ms to 12.7ms. 50th percentile times remained a bit better with the 5.1-facebook build over the sample period, 0.185ms vs. 0.194ms. Many query types were 4-15% faster with MariaDB 5.5.30 under production load, a few were 5% slower, and nothing appeared aberrant beyond those bounds.

第一台觀察一陣子沒問題後,接下來一台一台換掉。然後發公告慶祝 :p

在 FreeBSD ports 裡用 local patch 修正問題...

FastCGITrac,遇到 Trac 常常出現 MySQL server has gone away 的問題,官方看起來非常的 open source style:我沒遇到,不太想要處理這個問題... XD

Anyway,這個問題可以透過「#3645 (MySQL connections don't reconnect after idle timeout) – The Trac Project」的 comment:8 給 workaround 掉,但我不希望在升級後問題又跑出來,所以就用「Apache 2.2 worker MPM 與 mod_fastcgi 的問題」這邊的解法來解了:

www/trac: NO_CHECKSUM=yes | PATCH_SITES=http://freebsd-patches.s3.amazonaws.com/trac/ | PATCHFILES=patch-trac__db__mysql_backend.py

不過 NO_CHECKSUM=yes 有點討厭,來找看看有沒有辦法「增加 checksum」而非「忽略 checksum」...

把 screen 的 BIG5 換成 UAO (Unicode-At-On,Unicode 補完計畫) 版本...

目前 Ptt 上使用者用的編碼不是單純的 BIG5,而是 BIG5 加上 Unicode 補完計畫的版本 (拿了 BIG5 的造字區去對應某些常用的缺字)。

如果用 BIG5 去看假名就會變這樣:

所以在 Ubuntu (系統內建的 Terminal) 或是 Mac OS X (用 iTerm2) 上 Ptt (以及 Ptt2) 時都是用 BIG5-HKSCS 編碼,可以顯示日文假名:

不過還是可以看出來漢字不太行,所以還是去找了 UAO 的方案...

第一個想法是直接換掉系統的 BIG5,反正只剩下 BBS 用途要用了,就一次換掉。不過找了半天沒看到現成的工具,雖然在「Mozilla 系列與 Big5 中文字碼」有表可以轉,但還是懶的改...

另外一個是 GNU Screen patch,依照「Screen + Unicode-At-On」這篇的方式,可以生出一個 UTF-8 terminal + converter (GNU Screen),效果就是這樣:

可以看到漢字也出現了... 來找看看要怎麼把 patch 包進 FreeBSD ports 好了...

用 Unbound 跑處理 DNS Round Robin 服務的問題...

環境是內部有兩台互相做 HA 的 server (用 Heartbeat 或是用 CARP),然後給一個內部用的 domain 指到兩個 IP address,於是發現不太平均:「Unbound 回傳 RR Set 的順序問題」。

2010 年的時候就有人提過要這個功能,然後被打槍:「[Unbound-users] Round Robin DNS」,最主要的理由是「這應該是 client 要做的事情」。

2012 年三月有人決定自己來:「[Unbound-users] patch implementing round robin rrsets」,patch 本身蠻簡單的 (不過看起來不能保證 thread-safe),另外也有一些 RFC 隱性希望 DNS resolver 可以處理 round robin 的事情。

四月的時候有人把 patch 修過,解決了 thread-safe 問題:「[Unbound-users] patch: rrset-roundrobin/minimal-responses」。

看起來之後的版本有機會內建了...