Hacker News 的 API

Hacker News 一向是個重要的資訊來源,以往大家要分析 Hacker News 上的文章都是自己硬幹:爬網站的結構後再做後續處理。而現在總算是不用全部硬幹了,官方提供 API 讓大家存取:「Hacker News API」。

透過與 Firebase 的合作 (YC S11,Y Combinator Summer 2011),Hacker News 的資料可以透過 Firebase 提供的 API endpoint 取得了。

接下來應該可以看到更多資料被丟出來玩?

Windows 10 都市傳說的佐證...

續上篇「Windows 10 的都市傳說...」,先不管微軟內部的 code 如何,以及跳過 Windows 9 的真正原因,但 open source 專案的確有不少人這樣判斷 Windows 95 與 Windows 98:

還有各種變形的:

		} else if (osName.startsWith("Windows")) {
 			if (osName.indexOf("9") != -1) {
 				jvm = WINDOWS_9x;

這該怎麼說呢...

Ubuntu 下 VMware Tools 的替代品 Open Virtual Machine Tools

VMware 裡面跑 Ubuntu 通常會安裝 VMware Tools,像是「VMware Tools for Linux Guests」這篇介紹的方法。

但官方介紹的方法比較麻煩一點,所以想要從現有的套件裡找看看有沒有現成的可以用,然後就找到「open-vm-tools」,而且看起來已經存在一段時間了,12.04 (甚至 10.04) 都有支援。

裝好後就可以馬上看到更新:

應該是沒問題吧...

GlobalSign 提供 Open Source 專案免費的 SSL Certificate

GlobalSign 提供 Open Source 專案免費的 SSL Certificate:「Free SSL Certificate for Open Source Projects」。

不過看了看需求還蠻龜毛的,不如自己花個 USD$10/year 還比較方便。如果不在意時間成本的話就申請吧,我猜實際上也不會有多少專案申請...

Netflix 與 Comcast 的恩怨

其實就是商業公司之間的勾心鬥角,在包裝後搬到檯面上 :p

Netflix 在美國固網裡吃的流量比 YouTube 還多,可想而知當然就變成各 ISP 找麻煩的對象...


出自 Sandvine 的「Global Internet Phenomena Report 2H 2013」。

Netflix 有多種方式將影片傳遞給使用者。除了早期自建機房外,後來跟不少 CDN 有業務往來 (包括了 AkamaiLimelightLevel3),另外也有 Netflix Open Connect Content Delivery Network 計畫,直接在 ISP 內部機房放設備提供服務。

使用 CDN 的作法成本太高,而 ISP 又不一定會接受 Open Connect 方案 (因為不一定收的到錢),在這種情況下,如果走 transit 線路的速度通常都不會太好。而 Netflix 與 Comcast 之間的狀況就是如此:

在付給 Comcast 錢後速度都都解決了...

除了付錢解決外,上個禮拜 Netflix 就丟出一篇說明的文章發難了:「The Case Against ISP Tolls」,這篇文章除了提到上面的事情外,另外還極力反對 Comcast 與 Time Warner Cable 的併購案 XDDD

然後最近又炒熱的網路中立問題,看起來也這件案子應該會很熱鬧 XDDD

Mozilla 推薦的 jsDelivr?

Mozilla 在「jsDelivr – The advanced open source public CDN」這篇文章裡面推薦 jsDelivr 這個服務:

Similar to Google Hosted Libraries, jsDelivr is an open source CDN that allows developers to host their own projects and anyone to link to our hosted files in their websites.

GitHub 當作 origin server,前端目前利用 CloudFlareMaxCDN,配合 Cedexis 的 openmix 服務,綜合這兩家 CDN 提供服務。

既有的 cdnjs.com 是由 CloudFlare 贊助的服務,那 jsDelivr 呢?

看了老半天得到這些訊息:jsDelivr 是由 @jimaek 所發起的服務,而 @jimaek 受雇於 MaxCDN。再加上 Mozilla 上的文章也是 @jimaek 發表,而且只發表過這一篇 (參考 Articles by Dmitriy Akulov),這邊的目的也太明顯...

應該可以每幾天就看一下下面的 comment,不知道什麼時候會引爆利益衝突的問題...

擋 Open Redirect 的問題...

Open Redirect 的問題可以參考:

這兩個連結。主要是要避免 phishing 的問題上。

一開始是以「只允許 / 開頭」為條件過濾,但 protocol-relative 的 //www.example.com 可以繞開。

如果變成「只允許 / 開頭,但不允許 // 開頭」,是不是就沒事了呢?

在「Evolution of Open Redirect Vulnerability.」這邊又看到新招:「/\www.example.com」。

想要用 parse_url() 檢查?沒問題:

$ php -a
Interactive mode enabled

php > var_dump(parse_url("/\\www.example.com"));
array(1) {
  'path' =>
  string(17) "/\www.example.com"
}

但實際測試會發現 IE8 與 Google Chrome 都會跳到 www.example.com (沃槽),其他瀏覽器就先不測了 ~_~

不過原文說的 ///www.example.comPHP 上測試應該是不會過的?

$ php -a
Interactive mode enabled

php > var_dump(parse_url("///www.example.com"));
bool(false)

反正又冒出一堆問題要處理了 ~_~

加州理工學院對於學術研究的公開公告

引用加州理工學院的「Caltech Announces Open Access Policy」開頭:

On January 1, 2014, a new open-access policy for faculty's scholarly writings will take effect at the California Institute of Technology (Caltech). According to this policy, approved by the faculty at their June 10 meeting, all faculty members will automatically grant nonexclusive rights to the Institute to disseminate their scholarly papers, making wider distribution of their work possible and eliminating confusion about copyright when posting research results on Caltech's websites.

正式決議並公告,讓研究員 (包含教授與學生) 可以很自由的在自己的頁面上放自己的研究 (論文或是文章)。

愈來愈多學術單位往這類公開政策邁進...

Cisco 的 H.264 實作放出來了...

Cisco 在十月宣佈的 Open source H.264 codec 已經在 GitHub 上放出來了:「Open Source H.264 Codec」,這個實作包括了 encoder 與 decoder。

用的是 BSD 2-Clause License:「LICENSE」。

目前的支援度:(直接複製 OS Support 這段)

  • Windows 64-bit and 32-bit (initial release is only 32-bit, 64-bit will follow soon)
  • Mac OS X 64-bit (initial release does not include this target, will follow soon)
  • Linux 64-bit and 32-bit (initial release is only 32-bit, 64-bit will follow soon)
  • Android 32-bit (initial release does not include this target, will follow soon)
  • iOS 64-bit and 32-bit (not supported yet, may be added in the future)

看起來目前只支援桌機上的 32bits...

然後已知的問題:(複製 Known Issues 這段)

  • Encoder errors when resolution exceeds 3840x2160
  • Encoder errors when compressed frame size exceeds half uncompressed size
  • Encoder console app only support multiple of 16 width/height for now
  • Decoder errors when compressed frame size exceeds 1MB

反正就繼續看著辦?