
ccpz's blog
2011年4月16日星期六
chrome extension: Auto HD for YouTube

2010年5月7日星期五
DNSSEC
之前看到一些消息,5/5 開始所有的 Root DNS 都會測試 DNSSEC,到 7/1 就會正式上路,也就是說到 7/1 第一層的認證就會開始運作了。接下來只要等其他的 TLD 給 root 簽過以後,就可以對目前使用中的 Domain Name 簽,這過程大概還要 1~2 年的時間吧。到時對岸應該很頭痛吧 XD 常見的 DNS 劫持都不能用了。
大概看了一些文件,其實概念蠻簡單的,就是套用了 PKI 的架構,然後上層 Domain 就扮演 CA 的角色做 key 認證。所以要從 root 開始,之後是 TLD,最後使用中的 domain 才有人幫忙認證。所以現在先留一些文件,等之後 VeriSign 開始做 TLD 的 DNSSEC 再說吧。
Ref:
2010年5月6日星期四
Intel 對 USB 3.0 的態度
Intel 對 USB 3.0 的支援都一直拖拖拉拉的。NEC 已經做出晶片,也已經有商品上市,可是 Intel 那就是沒消息。剛剛看到這篇癮科技的新聞:Intel 在筆電上示範 Light Peak,超過 10Gbps 的速度只是個開始 突然有種恍然大悟的感覺 XD 原來 Intel 想推自己的連接阜,而且接頭還和 USB 相容,很明顯就是要推這,不想弄 USB 3.0。再回頭看看 USB 3.0 草案時的一些爭議:
- Nvidia, AMD vie with Intel over USB 3.0
- Intel USB 3.0 update resolves dispute with Nvidia, AMD
- Nvidia confirms Intel won't back USB 3.0 until 2011
當初放棄這麼快,背後原因果然不單純 XD 就是決定自己弄一套,不和 USB 繼續玩下去了。
2010年4月21日星期三
迅雷
前幾天看 Apache log 時,發現了一個奇怪的現象:
* - - [21/Apr/2010:13:21:41 +0800] "GET *** HTTP/1.1" 206 65911 "***" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"
Log 出現很多抓這個檔案的 Entry,不過這檔案並沒有公開的連結,而且 User-Agent 都一樣。用這裡的 script 統計之後發現這個 User-Agent 佔了很大一部分:
# cat /var/log/apache2/access.log | awk -F\" '{A[$(NF-1)]++}END{for(k in A)print A[k],k}' | sort -n | tail
672 Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6.4; SLCC1; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.30729)
754 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
1080 Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2)
1092 Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)
1579 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1045 Safari/532.5
2003 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1045 Safari/532.5
2017 Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
2778 Microsoft-IIS/0.0 (internal dummy connection)
13463 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
26297 Mozilla/4.0 (compatible; MSIE 5.00; Windows 98)
找了一些資料以後,果然和我猜測的一樣,是迅雷在搞鬼(因為看到很多 IP 都是大陸來的):
照上面的方法用 mod_rewrite 把它的 User-Agent 檔掉,雖然 User-Agent 不可靠,現在要檔他只能用這種方法了。
RewriteEngine On
#Anti Thunder (Xunlei)
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.1\)$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.0\)$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.0\)$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.1;\ \)$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.0;\ \.NET\ CLR\ 3\.5\.20706\)$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows\ NT\ 5\.1;\ SV1;\ \.NET\ CLR\ 1\.1\.4322;\ \.NET\ CLR\ 2\.0\.50727\)$ [NC]
RewriteRule ^.*\.(gif|jpg|bmp|zip|rar|exe|mp3|swf)$ / [NC,F]
2010年4月13日星期二
Opera Mini for iPhone
拖了 20 天以後,想不到居然過了 (Apple 吃錯藥了嗎)。看他之前的宣傳說的這麼神,早上就弄了一個日本 AppStore 帳號去抓下來用用看。只能說期待太高了╮(-_-)╭,之後大概還是以 Safari 為主吧。
這張是啟動畫面,上方是 Opera 首創的 Speed Dial, 下面是 Tab 切換
這兩張是開啟聯合新聞網的畫面,雖然和 safari 一樣可以連點放大,可是就只能放大成右圖的大小,不能用 twist finger 自定放大倍率,連 safari 都做的到了,Opera 居然沒這功能 orz
Acid3 測試結果,有97分,不過畫面怪怪的。
開一個 google reader 看 web app 的效果,登入表單上就沒 Safari 那麼友善了。在Safari 還有上一個/下一個按鈕,可以跳到其他欄位,可是在Opera 中就只能用手去點欄位。登入後看到的只有很簡單的純文字網頁,不過這也不能怪 Opera,他送出的 User-agent 是這樣:
Opera/9.80 (J2ME/MIDP; Opera Mini/5.0.0176/1150; U; zh) Presto/2.4.15
所以 Google 大概當做一般的 Opera Mini 來提供網頁吧,根據這裡的說法,可以從 X-OperaMini-Phone-UA,X-OperaMini-Phone 去得到手機資訊,所以就看 Google 要不要支援 Opera Mini for iPhone 了。畢竟之前 iPhone 的 web app 只需考慮 safari 就好,接下來如果 Opera 的使用者多了,大家才會漸漸考慮到支援 Opera。
總而言之,雖然抓網頁和 Rendering 速度比 safari 快一些,但是 UI 和一些小地方的設計還是不比 safari 好。Opera 可能只是單純做移植,沒有考慮對 iPhone 特化,所以用起來還是沒 sfafari 順手。只能希望他會繼續更新了。
2010年1月7日星期四
2009年12月4日星期五
Google DNS: 8.8.8.8, 8.8.4.4
Official Google Blog: Introducing Google Public DNS
Google 現在連 Public DNS 都弄出來,看來真的要包山包海了。Google Code 上有一些設計說明,最近 Google 推廣速度上還真是不遺餘力,先是用 Chrome 示範瀏覽器可以跑多快,現在又用 Public DNS 示範 DNS Server 如何加強速度和安全性。Traceroute 後看來台灣也有 Server:
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
1 not-a-legal-address () 0.613 ms 0.795 ms 0.381 ms
2 not-a-legal-address () 0.861 ms 0.827 ms 0.709 ms
3 140.113.0.105 (140.113.0.105) 0.593 ms 0.689 ms 0.849 ms
4 Nctu-NonLegal-address (203.72.36.2) 1.232 ms 0.965 ms 1.107 ms
5 * TAOYUAN-G35-G0-2-HSINCHU.IX.kbtelecom.net (203.133.92.165) 3.465 ms 2.925 ms
6 u23-5.u203-187.IX.kbtelecom.net (203.187.23.5) 2.760 ms 2.178 ms 3.195 ms
7 u23-98.u203-187.IX.kbtelecom.net (203.187.23.98) 2.424 ms 2.349 ms 2.440 ms
8 72.14.196.9 (72.14.196.9) 2.701 ms 3.037 ms 3.068 ms
9 209.85.243.26 (209.85.243.26) 3.018 ms
209.85.243.30 (209.85.243.30) 3.570 ms 3.368 ms
10 209.85.250.103 (209.85.250.103) 3.725 ms
209.85.250.101 (209.85.250.101) 3.625 ms
209.85.243.23 (209.85.243.23) 3.421 ms
11 209.85.241.162 (209.85.241.162) 8.867 ms
209.85.241.154 (209.85.241.154) 7.030 ms
209.85.241.158 (209.85.241.158) 12.492 ms
12 google-public-dns-a.google.com (8.8.8.8) 4.337 ms 4.185 ms 4.029 ms
除了展示技術外,或許對之後 Chrome OS 也有幫助?如果預設用自己家的 DNS,可以避免使用者被奇怪的 DNS 檔掉。而且從 DNS query 上還可以統計到蠻多資料,更狠一點的話還可以學 OpenDNS 統計常見的 typo,導到自己的頁面去。