HiRadioTray 20100109 & Hinet Radio Script 20100110

HiRadioTray 20100109
檔案連結: HiRadioTray_20100109_ubuntu910_i386.deb

1. 根據 Hinet 更動了 mms 取得方式
2. 修正 奇美古典音樂網 格式
3. 修正更新功能

由於個人疏忽, 20091010版無法使用更新功能

使用 20091010 版本的使用者:
安裝更新檔者:
請移除 ~/.HiRadioTray 目錄後再執行程式即可

不想安裝更新檔者
請到此下載 update.sh 並覆寫原本 ~/.HiRadioTray 下的檔案, 以修正更新功能
請到此下載 get_mms.sh 並覆寫原本 ~/.HiRadioTray 下的檔案, 以修正收聽功能

Hinet Radio Script 20100110
檔案連結: radio_20100110.tgz
或執行 update.sh 更新即可

打造簡易監控系統 - ffmpeg + lighttpd

(TODO: 附圖)

由於個人與老婆必須工作, 平日就將寶貝女兒託給爸媽照顧
在家中, 女兒目前待在三樓塌塌米房間
然而難免會有需要短時間離開處理一些事務
能清楚知道baby何時醒了和哭了的時間很重要
因此母親希望能夠架設視訊系統, 方便在一樓能知道三樓狀況

的確, 最快的方式就是購買現成IP Cam產品
想想這部份的技術並不是非常高
所以第一時間想到的就是擺放在家中當床頭機的 EeePC 701
(老實說, 現在有點慶幸當時買的是有Webcam的版本, 那時嚷嚷我只需要長效電池)

接著就是作 video streaming 了
其實依開始我想到的是使用 VideoLan 來作
然而設定/使用與過高的CPU loading都不讓人滿意
加上是給父母操作使用, 使用過程愈簡單愈好

朝 flash video 方向尋找方案, 發現 ffserver/ffmpeg 是個不錯的選擇
參考ffmpeg的這篇討論文章, 搭配需求將設定檔做了些許更動
像是加入了Audio部份, (ffmpeg 的啟動指令亦必須加入 -f oss -i /dev/dsp)
另外提高VideoFrameRate至15, 移除了 VideoIntraOnly, 加入VideoGopSize 以降低bitrate
原本只打算使用 swf 格式, 如此browser 可以直接開啟播放
然而個人設定 SWF 搭配 Audio一直無法順利啟動
(如有設置上限制, 歡迎告知指正)
只好轉而使用FLV, 測試後,VGA frame, 15FPS 加上 Audio
在 630Mhz 的 EeePC, CPU loading 約為 50~60% (打開900Mhz 模式, 降低到 33%~40%)
設定好後, 假設存檔為 webcam.conf, 如此執行指令 "ffserver -f webcam.conf"
就可以在 http://MACHINE_IP:8090/webcam.flv 收到 streaming video/audio

使用 FLV 相較於 SWF 比較麻煩的是需要 flv player
browser 上需要 swf 元件來處理 flv video
網路上免費solution不少, 像是37-flvplayer.swf與GPL的flowplayer
最簡單的方式, 就是寫個 HTML, 連到提供該元件的主機, 搭配 flv 來源URL
為了降低對外部網路系統的依賴, 搭配輕巧快速的 lighttpd 來使用是不錯的選擇
(Apache?! 殺雞焉用牛刀.)
下載好 swf 元件, 依照各個swf flvplayer 規格撰寫個簡單的 HTML
放置於 /var/www 後就完成了

如此, 一樓電腦打開browser, 設好首頁, 就完成了

想想, 在 embedded 產品上, 將 hw codec 整合至 ffmpeg 是個不錯的作法
如此很快就可以建立具有網路傳輸功能的分散式 IPCam

關於 Chrome OS 的另一觀點

今日很榮幸受到先前在NCHC主管Steven的邀請
分享一些關於Chrome OS 與 GO 程式語言的心得

Chrome OS Observation

View more documents from Champ Yen.

在Chrome OS推出時, 難免將此與Google 要正面挑戰 Microsoft 做連結
並且以個人裝置的用途來思考, 因此Chrome OS也就相形見絀
在此回歸以Chrome OS的三大特性 - 快速, 簡單, 安全的方向思考
也許 Google 所規劃的是不同方向的佈局

Chrome OS - 網路作業系統時代的來臨?

回想當年, 微軟為了擊敗如日中天的Netscape
刻意將Internet Explorer 內建於Windows 系統
在反托拉斯官司中, 微軟宣稱 IE 是 Windows 系統不可分割的一部份
今日Google 推出的 Chrome OS 中, Browser 的確是系統不可分割的一部份

在Google發佈Chrome OS計劃細節後,
相關的新聞已經在網路上迅速蔓延了開來
Chrome OS之所以受到如此的注目
是因為媒體將Chrome OS解讀為Google用以挑戰微軟的開始
而若不是Google盛名, Chrome OS或許也無其特殊性.

今日原本抱著期待的心尋找Chrome OS的資訊
反覆觀看計劃相關的技術文件與設計說明後,
甚至覺得有些許說不上來的感覺
Chrome OS 計劃很難與創新聯想在一起
在看完這篇文章後, 我也釐清了一些想法

網路上對於Chrome OS介紹相當的多, 這裡就不做詳細的介紹
Chrome OS 是個 Web Browsing/Application 導向的作業系統
最重要的特性是不支援也不仰賴任何其他程式,
所有應用全部依靠Web Application
因此使用者資訊完全存放於網路上, 在電腦上完全不存放任何資訊
因為如此, 系統的確能夠精簡到基本的OS, Driver & Browser, 開機快速
而不做任何更動的檔案系統, 做檢測相對上較容易, 安全性上也很好

對於Chrome OS這樣的設計,
最大的問題也在於全面網路化的時代來臨與否
說穿了, thin client並不是甚麼特別新的觀念
從早先的終端機到宏碁提出的專用電腦XC,
都是類似概念下遭到淘汰的產物
儘管現今網路應用在比以往充實許多
而這些Web Application是否真的能夠大幅取代原生軟體應用?
單單 Youtube/Lala 能夠取代一般使用者的影音需求?
列印, 照片處理, LAN檔案分享, 這都已經是普遍的一般應用

的確, 有人可能會說Chrome OS 可能定位不在此
但這樣的情況 Chrome OS 只能定位為電腦上第二個作業系統
快速開機, 上網, 安全無負擔, 在許多臨時應用上確實有其市場
然而在這個市場上已有既有實作像是著名的Hyperspace
類似環境所提供的軟體也遠甚於一個browser
甚至個人認為同樣在Web App導向的思維下
Intel Moblin v2在系統設計上的也優於Chrome OS
實用性遠遠超過 Chrome OS

而除了技術觀點上的問題外
Chrome OS 還需要挑戰人們對於資料放在網路上不安的心理
本地端資料檔案處理 & 多媒體的大量需求
以及對於原生軟體功能性的需求與追求多多益善的心態..

若Google 後續不正視與修正Chrome OS 對於 local 原生軟體應用需求的策略
那麼Chrome OS 難免落入對於網路應用一廂情願的泥淖中..

令人期待的 GIMP 2.8

GIMP 2.7 的 single window mode


先前就聽說GIMP 2.8將要支援許多人引領期盼的 single window mode
雖說個人並不是很排斥GIMP原有的multiple window
但在Ubuntu Netbook Remix 下, 過多視窗就顯得不易使用
原本是指望Paint.Mono, 然而目前在Linux上有許多問題, 連堪用都稱不上

今日看到了一篇國外的blog文章
發現Single Window Mode 看來真的是很棒
相當簡潔, 不會有凌亂的視窗

於是叫出安裝已久的GIMP 2.7
果然single window mode 有相當雛型
目前看來UI的版面配置的調整有些問題
但是配置好後, 看來真的是挺有那麼一回事

由此看來, 等穩定後推出的正式版本 2.8 應該是相當令人期待

Google Go - C 語言的進化

Go Language 吉祥物 - Gordon 田鼠

自上次更新blog 至今有許多大則的資訊相關新聞
像是 Ubuntu 9.10 與 Android 2.0的發佈
MontaVista 與 3Com 被併購 等等

令個人注目的就是標題上談到的Google所提出的 Go Language
個人認為, 對於喜歡 C 語言的程式設計師而言, Go 會是另一個開發利器

對於Go 的背景資料, 個人就不在此詳加介紹了
在搜尋網站上搜尋就可以輕鬆找到一大堆

Let's Go.

一進入 Go 官方網站, 即說明了Go 語言的特點 - simple, fast, safe, concurrent and fun
的確, 沒有比這更簡潔有力的介紹了

從官網的範例看來, 乍看之下會以為Go又是個了無新意類似 C++/Java 的語言

package main
import "fmt"

func main() {
fmt.Printf("Hello, 世界\n")
}

是吧? 可是官網開頭範例竟然是個天大的陷阱, 從package, import 到 fmt.Printf()
一旦接著好好咀嚼 Tutorial 的話, 會發現 Go 真的蠻奇特的, 甚至與原本所想的相去甚遠

C++/Java 程式設計師第一時間可能是發現到了 - 沒有class, object!
(沒有繼承多型, 我怎麼唬人(誤))
接著會注意不太一樣的variable/function declaration (Goroutine 這是啥!?)
與不太順眼的 if-else, switch, for ...
還有看都沒看過的資料型別 - Slices/Maps/Channels (有 String 囉)
一開始摸不著頭緒的 interface

在語法上 Go 提供了精練且概念呈現較清晰的方式
像是變數宣告:
var Foo [10]int;

且流程控制的語法更為彈性
像是switch:

switch {
  case '0' <= c && c <= '9':               return c - '0'       case 'a' <= c && c <= 'f':        return c - 'a' + 10       case 'A' <= c && c <= 'F':               return c - 'A' + 10    } 

另外像是 function 可以有多個 return values
語法上有諸多新的特性, 就留給大家慢慢發覺

除了語法的改良外

如同 C 語言, Go 依然是以 struct 為主
資料處理的方式, Go 採用了與 C++/Java 物件導向不同的 data - interface
在 OOP 中 data (member) 是依附特定 function (member function)處理
data - interface 中, 並不將資料與介面做緊密的結合, 而僅是有其關係
這樣的方式除了具有彈性外, 資料的操作上也較為直覺, 並且負擔較小
相對地也是達到code reuse 的另一種方式

官網 Tutorial 的 範例 - Sorting:
這是個能夠排序的function (Interface 是 interface 名稱)

func Sort(data Interface) {
    for i := 1; i <>
        for j := i; j > 0 && data.Less(j, j-1); j-- {
            data.Swap(j, j-1);
        }
    }
}

所制定的 interface

type Interface interface {
    Len() int;
    Less(i, j int) bool;
    Swap(i, j int);
}

如此 Sort 可以套用在任何實作此 Interface 的資料型態
範例中列舉了int array (non-struct)與 day(struct)

type IntArray []int
func (p IntArray) Len() int           
{ return len(p); }
func (p IntArray) Less(i, j int) bool 
{ return p[i] < p[j]; }
func (p IntArray) Swap(i, j int)
{ p[i], p[j] = p[j], p[i]; } 

func ints() {
  data := []int{905, 0, 0, 42, 7586, -5467984, 7586};
  a := sort.IntArray(data);
  sort.Sort(a);
  if !sort.IsSorted(a) {
      panic()
  }
}

type day struct {
  num        int;
  shortName  string;
  longName   string;
}

type dayArray struct {
  data []*day;
}

func (p *dayArray) Len() int           
{ return len(p.data); }
func (p *dayArray) Less(i, j int) bool 
{ return p.data[i].num < p.data[j].num; }
func (p *dayArray) Swap(i, j int)
{ p.data[i], p.data[j] = p.data[j], p.data[i]; } 

而其他還有許多值得玩味的部份 - 像是Go 所強調支援的 concurrent 的支援, 與 Memory Model (Go 具有 Garbage Collection)
在此就不詳盡一一介紹了, 官網上的 Tutorial, Package Document 與 Effective Go 都是優質的文件資料

如官網 FAQ 所回答的, Go 概念上很多部份源自於 C
然而特性上有混合不少其他類型語言的感覺
相信喜愛 C 的人多半會樂於接受這樣的演進
另外Go 還是發展中的語言, Compiler 還在開發中
目前還缺乏動態連結的能力, 目前僅能編出靜態連結後的執行檔
儘管目前 Go 尚未廣泛地被應用, 然而依然可以從 Go 的設計看出所俱備的潛力

Android 已移植至 PowerPC 平台 & Android 2.0 釋出

在兩年前的拙作"到底 Google Android 是甚麼"一文中提到
Google Android 建構了標準 library 環境與使用Dalvik VM是相當聰明的規劃
相較於WinMobile 與 其他Embedded Linux Distribution而言,
Android這樣的系統特性使得在硬體平台轉換時, 依然保有長期累積的應用軟體資源
當時已可看出Android的架構並非依附在特定硬體平台上.

這樣的特性對於系統與SoC廠商這都是樂觀其成的事情, 特別是使用非ARM Processor的廠商
而這個效應正逐漸發酵中, 繼Android移植到MIPS後
近日LinuxDevices.Com上的新聞顯示現在也已經移植到PowerPC
可以遇見的是, Android 平台的優勢會漸漸浮現

同樣面對多元的硬體平台, 然而Microsoft 由於 Wintel 的成功經驗
預期相同的策略能夠在手持式平台市場複製
在Handheld Device上 Windows Mobile 硬體平台上決定限制使用ARM平台
雖然以此解決了硬體平台多元的問題, 如此的決策也造成了硬體的排他性
並非根本解決軟體相容性問題, 而相對地也同時樹立了非ARM平台業者的敵人


另外在 1.6 版發佈的一個半月後, Android 2.0 釋出了
在功能的改進與新增上有不少的更動