The Pirate Bay 四位被告被判有罪

投影片還沒做完,但這件事情太大條...

The Pirate Bay 的四位被告被判有罪:「The Pirate Bay Trial: The Official Verdict - Guilty」。

四個人都判刑一年,以及總額約一億兩千萬 (新台幣) 的賠償。這四位會提起上訴,然後自嘲「好萊塢教我們,好人一開始總是處於弱勢」。

GPhone 使用的情況

從「Some Fun Facts About The Google Phone」這篇看到 T-Mobile 的 CEO 在 CTIA 透漏 Google G1 使用情況。

由於是 T-Mobile 的 CEO 直接公開的,所以這些數字很寶貴 (不是估計值):

  • 80 percent of G1 owners browse the web daily.
  • Four out of five G1 owners download apps at least once a week from the Android. On average, T-Mobile G1 customers have each downloaded more than 40 applications from the Android Market.
  • An average G1 owner consumes 50 times the data of the average voice-centric phone user.
  • Among T-Mobile customers who have purchased the G1, roughly half have traded up from a basic handset.
  • The majority of T-Mobile G1 owners use Facebook and YouTube at least once a week.
  • Half of G1 customers also access Wi-Fi on a daily basis.

另外一個隱憂是隱私問題,那又是另外一回事了...

在同一台機器上同時有 BIG5 與 UTF-8 Terminal

因為連上 BBS 還是透過 BIG5 比較方便,所以現在會在同一台機器上掛 BIG5 的 screen 與 UTF-8 的 screen。

首先是修改主機的 /etc/ssh/sshd_config,增加 AcceptEnv LANG,表示 server 會接受 client 所送出的 LANG 環境變數,然後在 PuTTY 的設定裡將 LANG 設為 zh_TW.Big5 或是 en_US.UTF-8 (或是 zh_TW.UTF-8):

登入後 LANG 變數就會被帶進系統內。

然後,vim 會判斷 locale 而決定 encoding 及 termencoding,所以本來寫死的部份都要拿掉。

這樣在 BIG5 環境下可以連上 BBS,用 vim 編輯一些資料...

用 freebsd-update 將 FreeBSD 7.1-PRERELEASE 升級到 7.1-RELEASE

依照 http://update.freebsd.org/,7.1-PRERELEASE 並不在升級範圍內,所以會出現像這樣的訊息:

$ sudo freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching public key from update2.FreeBSD.org... failed.
Fetching public key from update1.FreeBSD.org... failed.
No mirrors remaining, giving up.

由於 freebsd-update 是 shell script (有很多 undocument variable 可以調整),依照「"freebsd-update fetch", fetching public key failed.」這篇的點子,有個邪惡的方法可以拐 freebsd-update,讓他認為系統是 7.1-BETA:

env UNAME_r=7.1-BETA freebsd-update upgrade -r 7.1

這個方法可以用看看... 當然,這個方法一定會有一堆問題,如果對 FreeBSD 不熟的人應該會吃鱉 XDDD

CDN - 要怎麼挑業者

要挑什麼 CDN 是依照需求而決定,我會談的是台灣的情況。

在台灣有「用戶」的 ISP 中,HiNetTANet 的出國線路狀態是最差的,其他 ISP 的情況會好很多,所以測試的重點要放在這兩個 ISP。

以影音來說,由於傳輸時間普遍會大於一秒,重點在於 bandwidth 而非 latency。所以到台灣抓與香港、日本,甚至到美國抓其實都 okay,只要 thoughtput 夠高就可以。以 1M 高畫質的影片換算,有穩定 150KB/sec 的速度其實就很順,如果是 600K 或是更低,有穩定的 100KB/sec 以上就 okay。

如果是 css/javascript,因為檔案很小,latency 就變得很重要。可以從台灣本地提供檔案通常是最好的 (<10ms),或是從日本、香港 (~20ms 到 30ms) 提供,如果 CDN 業者可以幫忙 gzip 會更好 (因為他們會處理 IE6 的一卡車問題)。

如果檔案是屬於下載性質,速度其實不是重點,重點在於成本的話,有些 CDN 業者有提供「經濟型網路」,通常是用北美較便宜的點提供下載。有一定的 commit 時會比 Amazon S3 的 USD$0.17/GB 便宜。

除此之外,會因為不同的性質,要考慮的還很多...

CDN - 服務提供者

前三大 CDN 服務提供者:

其中 PIXNET 用的 Panther Express 前陣子被 CDNetworks 收購。

另外,很熱門的:

Amazon CloudFront 有公開的價錢,Akamai 與 Limelight 也有可以參考的價錢:(只是參考用)

其中 Akamai 國內有代理商 (併力科技)。

另外還有一些可以參考 Wikipedia 上的表。

CDN - 技術面

要決定使用者應該要到哪組 server 通常有這些方法:

  • GeoDNS
  • Anycast
  • HTTP Redirect (會比較差)

這幾種不衝突,常見的是前兩者搭配著用。將 DNS server IP anycast,當下載者要抓某個 domain 時,近的 server 就會知道大致的區域。再配合 GeoDNS 判斷使用者的 IP address 適合到哪個 node。

不過這些問題對 HiNet 就很麻煩。(留到現場講)

再來就是 reverse proxy cache 所產生的問題,這個部份再想看看要怎麼寫。

CDN - 為什麼要用 CDN

用 CDN 最常見的兩個理由:

  • 速度:下載者可以就近取得檔案。這對於小檔案 (css/javascript) 會有很大的幫助。(也許要解釋瀏覽器 HTTP 的運作,並抓一張 Firebug 的畫面分析?)
  • 效率:因為下載者透過 CDN 下載,可以減少原始 server 的負荷。

另外還有其他的理由:

  • 成本:這個留到會場講。
  • 安全:以分散架構對抗 DDoS 攻擊。

CDN - 什麼是 CDN

剛剛才發現 OSDC.TW 2009 有 50mins 的時間,先把一些資料整理出來,做投影片會比較方便。(大概會做 25mins 的投影片吧)

CDN (Content delivery network) 被稱為「內容傳遞網路」是一種內容快取機制,能提供高效能 (包括使用者以及內容提供者)、高可靠度、低成本的內容傳遞架構。不過,這幾個優點並不一定同時會發生。

以對使用者高效能這點,通常指的是「就近取得檔案」,內容提供者事先將檔案推到全球的 CDN 節點,在台灣的下載者儘量從台灣取得檔案,在日本或香港的下載者也儘量從當地的伺服器取得檔案。

由於在全球有多個節點,所以當某個節點不通時,可以導到次近的節點以達到高可靠度。

對內容提供者高效能的部份,是因為內容提供者不需要在一個 data center 上建立非常粗的水管。舉例來說,如果傳遞需要 100Gbps 的流量,利用 CDN 架構,每個 data center 也許只需要 5Gbps 的流量。由於十個 10Gbps 網路與 100Gbps 網路的成熟度不同,成本也會不相同。

這是 CDN 的一些粗略的概念。