Category: Technology

軟體相關

Posted on
by

順便提一下排名第二的音樂下載軟體 – ezPeer+。話說 ezPeer+ 其實為了 Linux 平台開了一版介面 ezPeer+ for Linux 1.0，是使用 XULRunner 與 mplayer 等軟體元件開發。

後端直接呼叫 mplayer 接取線上串流，會同時執行前端介面與後端播放軟體。偶爾會因為軟體處理不當，造成使用者按下暫停時，系統依然於背景播放音樂。稍微有點惱人的小問題。介面上也未提供進階選項，如調整快取大小等，我在 Seednet 上聽取音樂有點停頓。

此外大約是為了 mplayer 拿掉了 Windows Media DRM 功能，目前並沒有提供下載的功能，只能聽線上串流音樂，不過這應該已經可以滿足很多想在 Linux 上享受音樂的朋友。

可惜的是 ezPeer+ for Linux 目前只提供給 ASUS EeePC 的使用者使用，並未提供下載。若你購買了 EeePC，其實可以透過 dpkg-repack 重新將程式包成 .deb 檔案後丟到其他的 Debian/Ubuntu 上執行。

我說，你們這些多媒體娛樂資訊商，快照顧照顧我們卑微的 Linux/Unix 使用者吧。

Posted on
by

上次用 Wine 1.0-rc1 測試了一下 KKBOX，由於上次測試時使用 Wine 實做的 ShDocVw 與 MsHtml 等元件。由於無法透過內嵌的網頁登入，因此大部份某些功能無法順利使用。

但你若先將 Microsoft Media Player 與 Microsoft Internet Explorer 裝進 Wine 中，就可以順利執行起 KKBOX 了！安裝過的過程十分繁複，因此我其實是透過 wine-doors 與 IEs4Linux 才安裝成功。由於 IEs4Linux 預設會安裝一個獨立的 wine 系統，並把軟體預設安裝 $HOME/.ies4linux，因此必須稍加修改 IEs4Linux，以便強迫它安裝到正確的 wine 目錄。然後再重新安裝執行一次 KKBOX 即可成功啟動啦。

使用狀況倒是沒有甚麼問題，可聽取線上串流，離線下載由於尚未購買月卡，還無法測試。目前的一點點小問題是，左邊的選單還是亂碼，一般下拉式選單倒是沒有問題。此外嵌於軟體首頁的 Flash-based MV 會有嚴重閃爍的問題。

這是在 wine 1.0-rc1 與 wine 1.0-rc2 上測試。待有善心人士整理 Step by Step HOWTO. 或者乾脆整理成單鍵安裝程式吧。

Posted on
by

週二出席 Tossug 聚會的時候，來了一位英國來的外國朋友。由於外國朋友雖然來了台灣八九個月，但是尚未學會中文。在辨識中文字上有很大的困難，而且很難自行透過查字典的方式學習。

他分享了一個線上字典網站，叫 N 詞酷 (nciku.com)，這網站居然整合了線上手寫辨識，就算不知道怎麼發音，也可以試著繪出中文字，系統會自動辨識。對外國朋友實在方便！

據聞是整合了北京書同文公司巧筆系統，辨識率不差呢。John Pasden 為 Nciku 做了一些有趣的辨識率測試。


Source: John Pasden, nciku

Posted on
by

剛剛試著查找一些 GAE 的相關應用資訊的時候，在 App Gallery 上看到幾個還算不錯的好玩網站，其中不少 Twitter 類似或使用 Twitter 資料的網站 (因為 twitter 越來越難用了?)

如果你還不知道 GAE 是甚麼，不妨花幾分鐘聽一下 Google 在 Campfire One 的簡短說明，其中 Guido van Rossum (Python 的作者, Google App Engine 成員之一) 也給了一段演講

Campfire One: Introducing Google App Engine (pt. 1)

Campfire One: Introducing Google App Engine (pt. 2)

Campfire One: Introducing Google App Engine (pt. 4)

Campfire One: Introducing Google App Engine (pt. 5)

Campfire One: Introducing Google App Engine (pt. 6)

Posted on
by

長久以來，一直為了一個小小的資料庫系統尋找適合的解決方案。這個系統的基本概念是要建立一個可以大量收集與處理 Metadata 的資料模型。由於這只是一個 Pet Project，在無法額外投資建立叢集系統的狀況下，只能試著用一些簡單的方式來實做。

這個資料庫的用途是可利用透過各式 Metadata 所組成的 Facts 進行推論。稍早的實驗，已經可以有效率的進行基本的前推式(Forward-chaining)與回溯式(Backward-chaining)的混合式推導來取出有意義的「knowledge」。

我的資料形式都是 subject-predicate-object 表示的 RDF Triples (RDF: Concepts and Abstract Syntax)，原本是專注在可以處理 RDF 的 Triplestore，但大部份的開放原碼後端資料庫都還是使用 RDBMS，加上冗贅的 RDF/XML 資料交換格式，速度上實在難以令人忍受。而 ORDBMS 又需要使用不少的計算資源 (記憶體 :-/ ) 才能順利執行。

於是，策略性的將系統設計為 Controlled vocabulary，後端採用飛速的 SQlite。以速度來說，在有 VFS 快取下，從兩千餘萬筆資料中取出十筆的時間大約是 150ms。這種速度在使用上是毫無問題的，但如此一來毫無 Scalability 可言。問題之一是寫入的速度並不快，而且寫入過程資料庫便被鎖住，別說同時寫入，就是取用也是一個大問題。

於是，試著找一些可行的方案，如以 BigTable 為基礎的 Apache HBase, Hypertable，或是 Document-oriented database 類型的各式解決方案，如以 Erlang 開發的 Apache CouchDB, 基於 Facebook Thrift 架構的 ThruDB, Ruby 開發的 StrokeDB, 或 Java 為基礎的 FeatherDB。這些資料庫具備分散式且容錯的設計，而且都適合塞 schema-free 的資料。唯一的問題是你還是得自己架設一堆伺服器，才是「正」分散式、容錯設計。

直到最近 Google App Engine (視訊說明) 推出正式的服務租用價格，由於費用極為便宜，我便開始認真考慮是否可以把資料庫移到網路公司所提供的 Platform-as-a-Service。

Google App Engine 提供的是以 Python 語言為基礎網站應用軟體開發環境，其中提供 Datastore API，是基於 BigTable 上所開發，以提供了所謂 Scalable data-backed。另外一個價格與功能相仿便是 Amazon SimpleDB (但是 GAE 的硬碟儲存費用便宜多了)。這兩組服務所提供的都不是標準的 SQL 語法，而是特定的 API 搭配特製的查詢語法，Datastore 是 GQL, SimpleDB 則設計了自己的 query language.自然，網路上已經出現了根據此 document-oriented database 與 RDBMS 的交相論戰，如 Ryan Park 所寫的 Top 10 Reasons to Avoid the SimpleDB Hype 與 Yurii Rashkovskii (StrokeDB 的作者) 的回覆 Top 10 Reasons to Avoid Document Databases FUD。

對我而言，我並不需要 RDBMS 的特色，key-value 的資料庫形式已經可以滿足我的要求。問題在於系統是否可以處理我的需求，根據 High Scalability Todd Hoff 的文章指出，GAE 的 Datastore API 似乎有些速度上的問題、以及 Application Quotas 的限制，如此還必須實際再深入研究軟體的設計方式。而 Amazon SimpleDB 尚處於 Limited Beta 的狀態，因此還不能進行實際的評估。此外，目前這些方法還無法做 Path queries，是下一個研究方向。