發表文章

目前顯示的是 六月, 2008的文章

輪子不停重新打造,但我依然原地踏步

轉眼間 2008 年過了一半,時間流逝之快已不必再用言語形容,回想這十多年,自己從小毛頭長高長大到現在,到底有什麼不同了?

還記得 1996 年的某個晚上,手拿著一張磁碟片,憑著一條 64K 的專線,靠著爛到不行的英文能力,一一下載 img 和 tgz 檔,跌跌撞撞的裝著 Slackware Linux 4.0。辛苦到了天亮,終於在下 startx 指令的那一刻,看到滿是 X 符號的畫面,當時心情是多麼興奮。沒想到,一個一點用處的沒有的系統,也能讓人滿是成就感。

我不會寫程式,頂多在 Windows95 下用 VB 拉過幾個像是程式的東西,最多是會寫一點 HTML/JavaScript 及簡單的 DOS 批次檔。當時的我,完全不知道自己可以做些什麼,只會傻傻的看著螢幕上跟著滑鼠跑的小眼睛傻傻的笑,並崇拜著寫這個程式的作者。〔一個小學生的盲目崇拜〕

也忘了是相隔多久,因『偷聽』一些 ISP 的工作人員對話知道了 FreeBSD 的存在,在泡書店時找到了一本 FreeBSD 2.x 的書〔如果沒記錯,應該是黃綠色,作者我已不記得,但前陣子好像有聽人提起過〕。不過嚴格來講,這不能稱作是書,因為實在是沒幾頁,但安裝步驟清楚且詳細,讓我不費吹灰之力就把 FreeBSD 裝起來了。在過程中,很能夠感受到這本書裡所下過的功夫,以及作者的熱情。

或許是當時國內情勢的關係,開放原始碼這時開始快速浮上檯面,陸續有許多的人用『全身上下的熱情』去擁抱,實在好不熱鬧。一股莫明的感動,從為 Linux 中文化而誕生的 CLE、印象深刻的 OLS3 和 perl 的一切,到許多早期活躍於網路上的前輩們身上散發出來,使我至今仍無法忘記。還記得,當時的零用錢,近乎全數放在購買這些 Linux/FreeBSD 相關書籍上,因為這是我唯一得到參與感的方法。

時過境遷,一切卻等不到我學會寫程式。多年前,憑著剛習得的一招半式,在某個論壇提議用新架構,寫一些新的程式,卻被回覆:『這是開放原始碼的世界,不滿意改一改就好。』,那人又道:『有這麼多軟體可以選,何必重新造輪子?況且重新寫不一定比較好。』一席話衝擊並打消了我不少念頭。長久來的憧景和滿腹熱血,頓時消失得無影無蹤。

我好想,好想和當初的前輩們一同 Hacking,好想像當初的人們一同分享熱情,好想和大家一起往前開拓道路,好想,真的好想,可惜的是,我沒有機會,沒有機會…

一年一度的 COSCUP 又夠來囉

你的軟體用起來有問題?請打技術支援電話,由客服人員為你服務,他或許已經儘其所能,但
未必能解決你的問題。如果問題是軟體的臭蟲,你只好痴痴地等待不知幾年後才開賣的下一版
。而你當初之所以選用A軟體而不是B軟體,常常是聽信銷售員(sales)的一面之詞或同儕
的推薦。在這個行為模式下,users 面對的是銷售員和客服,coders 面對的還是銷售員和客服
,users 遇到的問題要間接地才能反應到 coders 手上,中間還可能會被過濾掉。
破除過往的迷思和痛苦,Open Source 帶來了全新的契機,所以在網路發達的今天獲得許多人的支持。在這不一樣的世界中,歡喜用的使用者,可以和歡喜做的開發者直接互動,可以更準確、快速的將問題和解決方式公開通報,並可以最快速度得到許多軟體開發者和有心人的反應和幫助。如此不一樣的軟體使用生態,令軟體不斷累積自身的價值,也造福了廣大的資訊科技使用者。 :-)

當然,除了從網路上交流,親自出來面對面接觸也是非常有意義的。在台灣一年一度的『COSCUP 2008 開源人年會』盛會,就讓樂於擁抱 Open Source 的人能共同來參與相聚。此活動將於『2008/8/23 (六) - 24 (日)』舉行,地點在『台灣大學 應用力學研究所 國際會議廳』,附有茶點,歡迎各界參加。

用 C 語言實作矩陣運算的 Function

業界上常用的 Matlab 軟體,因為本身就是為了做數學運算而設計,所以在數值分析和處理方面非常快速好用,但是在 C 語言就中沒有那些好用的指令和數學函式庫了,得自己打造所有的運算流程和架構。舉例來說,使用 C 語言來做矩陣運算,程式開發者都是先『指定行列數量』建立一個陣列,再『指定行列數量』去對內部的值,一一做處理或高斯消去解方程式,這比起 Matlab 中用兩行就可以搞定一切運算,可說易用性相差甚遠。

所以就想到,要是我們能設計出一套好用的 C 語言矩陣函式庫,是否就可以省下這些重覆設計矩陣運算流程的時間?於是可以做一些實作,來完成這個任務。

基本的矩陣資料結構:
typedef struct {
int rows;
int cols;
int total;
double *table;
} Matrix;

其中定義了幾個基本的 functions 做矩陣的處理:
建立矩陣:
Matrix *matrix_create(int rows, int cols)
矩陣最佳化:
Matrix *matrix_optimize(Matrix *matrix)
解矩陣的方程式:
Matrix *matrix_solution(Matrix *matrix)
顯示並列出矩陣內容:
void matrix_print(Matrix *matrix)
清空矩陣:
void matrix_clear(Matrix *matrix)

函式的程式碼:
void matrix_clear(Matrix *matrix)
{
int i, j;
double *ptr;

/* initializing matrix */
ptr = matrix->table;
for (i=0;i<matrix->total;i++)
*(ptr++) = 0;
}

Matrix *matrix_create(int rows, int cols)
{
Matrix *matrix;

/* allocate */
matrix = (Matrix *)malloc(sizeof(Matrix));
matrix->rows = rows;
matrix->cols = cols;
matrix->total = rows * cols…

判別WEP的ASCII與Hex型態之密碼

這是之前的一小則心得小記,一直記錄在桌面便條紙上,整理了一下。WEP 的密碼長度分為 40bits 和 104bits ,若是換成 byte 單位是 5bytes 和 13bytes,也就是 5 或 13 個 ASCII 字元。在 Linux 上,我們可以用 iwconfig 來設定 WEP 的 ASCII 密碼:
40bits 用 ASCII 表示:
iwconfig wifi0 key "s:12345"

104bits 用 ASCII 表示:
iwconfig wifi0 key "s:1234567890abc"
不過有些時候,WEP 會用十六進位表示密碼,因為每個字元由兩位十六進位碼表示,所以我們可以看到很長的密碼,用 iwconfig 來設定的話像這樣:
40bits 用 16 進位表示:
iwconfig wifi0 key "AABBCCDDEE"

104bits 用 16 進位表示:
iwconfig wifi0 key "AABBCCDDEEFF11223344556677"
由此可見,在一般情況下,只有在 5 和 13 個字元時會用 ASCII 表示,而其它字數時都是 16 進位型態,所以若是我們寫一個程式,判別用戶所輸入的 WEP 密碼型態,就可以用這種規則去識別。

開發時面對 GTK+ 臭蟲的一點小技巧

GTK+』是個易學的 Toolkit,用它來寫 Linux/BSD 上的圖形化界面,非常的簡單。用其開發出來的程式,除了可以在 X11 上運作,甚至是可以使用 DirectFB 直接將 GTK+ 程式畫在 FrameBuffer 上,所以 GTK+ 也常見於 Embedded System。

在 GTK+ 1.x 時代發展到最後,效能、輕量程度和穩定度都很好,目前仍然被許多 Embedded Device 所採用。但 gtk+ 2.x 之後的變革極大,每個版本都有大量的新東西,導致有些版本異常肥大,或有些版本異常 Buggy 都不足為奇。曾經也撰文寫過說,在開發 GTK+ 程式時,常碰到非常奇怪的問題,而除錯所花的時間少可以很少,多可能一兩天都不見得能找出問題。

這邊有些除錯的方法,可以幫助 GTK+ 開發者能找出程式上的臭蟲:

在執行欲 Debug 的程式前,先設好 G_DEBUG 環境變數:
G_DEBUG="fatal-criticals" 在產生 Makefiles 時,可下參數開啟 cast-checks 以得到更多的 debug information:
./configure --enable-cast-checks 用這幾個小技巧,就能比較容易發現 GTK+ 程式的錯誤。

不過如 PCMAN 所說,開發 GTK+ 程式時,放一套 GTK+ Source Code 在旁邊供著,還是比較有保障的〔笑〕。許多奇怪問題,還得靠 GTK+ Source Code 來釐清真相,速度可能比 Google 還來得快。

別以為『 GTK+ 哪這麼多問題?』,從很多 GNOME 和其他程式的 Code 就可以發現,為了解決 GTK+ 問題,有數不清的 Dirty Hack 和重寫。所以,和世界各地的 GTK+ Program 開發者聊到『GTK+ Sucks』時,總是能會心一笑和產生共鳴,不是沒有道理的。 :-)

後記
Open Source 最大的好處是讓開發者可以到處看 Code ,這意味著一切技術都是透明的,對於提升開發者自身能力上是很棒的。而對使用很多不同 Libraries 的 Project 來說,如果在有許多樣本的情況下,其開發者看 Code 的數量,其實就是程式碼品質的關鍵。所以,GTK+ 的 Source Code 當然也要看一下才是。 :D

成為俠侶 LXPC.讓 LXDE 與低價電腦雙宿雙飛

圖片
今年是『低價電腦年』,家家都打著 Low-cost PC 的旗號,從Asus、HP、Acer 再到最近的 MSI ,全都殺進這戰場。但縱觀整個發展,『低價電腦』似乎變成了『隨便一套 Linux +低等級硬體』代名詞。但也因為這樣,有了大量的 Linux 需求,讓每一家 Linux 發行商都使出渾身解數,設計出各自的特別操作界面,以取得廠商和消費者的親睞。

由於低價電腦的硬體本身比較差,所以上面運行的系統環境應該是要『快、狠、準』才是,若是使用『重量級』的環境和系統,拖著低等級硬體在跑,對使用者來說是最大的受罪呀!不過,『LXDE』還算夠輕盈,讓 LXDE 和低價電腦共結為連理,使 Low-cost PC 變成 LXPC,還真是個不錯的選擇!要知道,行走這『低價江湖』,結伴成『俠侶』去闖蕩總是比較溫暖和暢快的。〔別忘了 LXDE 還有隻神雕!?神燕?正可謂『神雕俠侶』呀 :D〕

EeePC 900 實體跑 LXDE

降速的 CPU - 630 Hz
在上面跑 Firefox 3.0 (只在右邊露出一小部份而已。汗)
加上桌面特效也依然不是問題

LXDE 下一階段目標是實作許多『好用』的系統工具和設定工具,如螢幕/投影機設定工具、網路連線工具、偏好設定等等;此外,也許會花些時間實作和研究一些 eye-candy 的東西,不過暫時不會當成主要工作,主要目標還是放在提升 LXDE 的可用性。


另外,除了改善對一般使用者的可用性,對進階玩家而言,尤其是 vim 和 command line 的重度使用者,Terminal Emulator 是必要的工具〔除非你是連 X 都不用的超級 Geek〕,所以 LXDE 現在也實作了一個建構在 VTE 上的 Terminal ,已經在這兩天釋出的『LXTerminal』就是這個實作。


LXTerminal 目前特色:
* 支援多重分頁。
* 沒有任何過度不必要的依賴套件。〔除了 gtk+ 相關之外,就只有 libvte〕
* 為減少記憶體浪費,所有的程式運作可共用一個 process。
* 當視窗、分頁和 VTE 的尺寸改變時,有正確的變化行為且處理效能良好。
* 支援共用 process時,使用速度極快的原生 Unix-socket 而不使用 D-bus。
由於目前手邊只有 EeePC 可以測試和開發,所以 screenshot 都是 EeePC 上的實…

GLib 就是懶.為一些 G stuffs 加上多國語言支援

一般來說,實作一個多國語言的應用程式,會在需要被翻譯的字串上做特殊標注或處理。為了減少標注所浪費的字元數,在 『gi18n.h』中更近一步定義了 _(String) 和 N_(String) ,用以取代原本的 gettext(String)。

事實上,多國語言支援的內部實作,就是呼叫 gettext() 去處理並依情況而填入不同語言的字串,當找不到符合系統語言的翻譯檔時,便會使用開發時所標注的原始語言。使用 #define 去定義成 _(String) 這種形式,也只是圖個方便使用罷了。

然而,N_(String) 又是什麼?和 _(String) 使用的時機不一樣,是用來針對一些 static variable 所提供的多國語言支援方法。之前說到,其實 _(String) 是使用 gettext() 這 function 做字串處理,這在多數狀況下都是可行的,但是在某種情況下,直接使用 gettext() 去對字串做翻譯替換確是有很大的問題。

用一些例子會更為清楚,宣告一個靜態的陣列,裡面事先填好一些字串〔這裡使用 GtkItemFactoryEntry 的資料結構當範例〕:
static GtkItemFactoryEntry menu_items[] =
{
{ N_("/_File"), NULL, NULL, 0, "<branch>" },
{ N_("/_File/_New Window"), NEW_WINDOW_ACCEL, newwindow, 1, "<stockitem>", GTK_STOCK_ADD }
};
其中,『/_File』和『/_File/_New Window』分別使用 N_(String) 被標示成需要被翻譯。為什麼在這不使用 _(String) 而是使用 N_(String) ?因為這是一個靜態的變數陣列,無法要求這陣列被存取時,使用 function 去動態取得字串資料然後再填入陣列,這本身並不符合陣列的行為和定義。可是,不能使用 _(String) 就意味著靜態陣列裡的字串,沒辦法支援多國語言。因此,N_(String) 就是在這樣的問題發生之下,被創造出來的方法,在這特殊的情況中被用來代替 _(String)。

N_…

新專案 LXTerminal 和 LXLauncher2 嘗鮮!

圖片
長久以來,總是找不到 Lightweight 的終端機程式,因此在 LXDE 上一直好像缺少了什麼。而 GNOME-Terminal 之肥,實在令人不敢恭維;XFCE4-Terminal 夠輕,但需依賴 XFCE4-Library ,在 LXDE 裡使用就顯得有點愚蠢;而 Roxterm 什麼都好,但效能極差,在我的 EeePC + Compiz 上,回應的速度實在是令人難以接受;至於 Sakura,因缺少 Process Sharing 機制,所以記憶體用量大,完全無法與 XFCE4-Terminal 相比;而 Evilvte 縱使省掉 GUI ,但因為 Based on sakura 所以情況差不了多少,Lilyterm 等其他號稱輕量的 Terminal,則也都幾乎有著相同的缺點。有些 Terminal 還使用了 Dbus ,更是先被我打上大叉叉。

其實這得怪罪於 VTE 本身的癡肥和問題,使 Terminal 的開發者沒有一個不用 dirty hacking 的方式,去解決所有的 Bugs 和減少記憶體用量,研讀各家的 Source Code 就能發現其端昵。在自己實作後,也發現其難度。

但為了使 LXDE 有個良好又輕量的開發環境〔只是為了這單純的目的〕,LXTerminal 還是誕生了,雖然目前功能不多,但可支援 Tab、更改字型、剪貼字串,比較可惜的地方是尚未支援 Process Sharing,所以記憶體用量上稍微大了些。不過此功能已著手開發,在正式 Release 時就會支援。

EeePC 上的 LXDE

另外從 Screenshot 裡可以看到,LXLauncher2 緒勢待發,架構其實已經完全改變,現在可支援多層目錄,背景也改用 Cairo 畫。其中有趣的是,改用了 gnome-menu 來處裡 .desktop 等分類的問題,不過別擔心, gnome-menu 並不需要依賴其他 GNOME 的東西,總體上也還算輕盈。

據 PCMAN 所說,在 svn head 的 gnome-menu 改用痴肥的效能殺手 gio,而現在版本只有使用 GLib,所以未來將考慮 fork 目前的版本,或許將會叫做 lx-menu 也說不定。

或許有人會好奇,LXLauncher 連 1.0 都還沒出,怎麼就出現了 LXLauncher2 ?因為 LXLauncher 一直…

頭痛.驚見.回憶予我

圖片
天天忙著解決數不清的問題,無論是為了興趣亦或是打工,總讓思緒不停得在轉動。不抽煙的我,不用抽煙放鬆自己,只能藉由許多其他的活動來讓自己短暫冷靜。最近,許多朋友需要傳一些資料給我,但他們總是將信寄到我的『Hotmail』信箱,只因為我的 MSN 帳號是 at Hotmail。無論我說了多少次請他們寄到我的『Gmail』信箱,他們還是將東西往我的 Hotmail 扔,一點也不理會我說的話。

奇妙的是,我登入 Hotmail 收信時,不小心點到了功能列上的『Spaces』,驚見被我遺忘且封存許久的記憶。


看吶!都是些高中時候的回憶,代表學校參加『台北市中運會』比賽時的照片〔最內道那是我〕,真是熱血少年呀。還記得第一次比賽時的緊張,到有經驗之後麻木沒感覺,整個過程令人難忘。還記得當時對各種運動的熱愛,讓許多老師一度問我『你是要去考體育系嗎?』,令我不知所措。

在 Spaces 中也記錄了很多高中時期的心情語錄,除了工作上的事,當然也有學校的東西,還有最後考 JCEE 的事,話說考試前一天我還在玩樂,一點也不緊張,活像個嗑藥的瘋子一樣。〔雖然考得不如預期的好,嘆。〕不過回顧這些記錄,彷彿重新經歷過熱血的當年。不像現在這麼的自閉,根本是冰血動物。

我很愛隨手用滑鼠畫畫,當時也留下不少筆跡,為朋友、學妹畫的東西,依然留存。

其中的服裝就是當時學校制服

還有太多的東西和『鼠』繪圖片,不過目前都雜亂無章的被擺放在一起,等哪天整理出來,再來釋出,也許還能採取 Free 形式的版權。〔不然某 P 先生會說 non-Free!拒看!:P〕

看了些輕鬆熱血的東西,整個人都有精神了起來。另外,文章開頭的圖 - 『困』,是陸續畫了好幾年的圖,從 Photoshop 5.x 畫到 Photoshop 6.x 再到 7.0,每當不開心就補上幾筆,其中怨念極深,不喜請略過(不過我想來不及了),這畫作直到高中畢業後便結束封存,代表新的開始。

現在回想,我何時開始忘了當初的執著和心情,新的開始應該是要開心的,怎能被這些惱人的思緒所打敗?

GLib 就是懶.用 GKeyFile 存取設定檔

過去曾撰文寫過『GLib』相關文章『初探 Glib Programing - I/O 處理事件化 g_io_channel』,其中講到 GLib 提供了許多功能的包裝,除了能讓程式開發者『輕易』實現『重覆又無聊』的功能外,又能確保其功能的穩定性,讓程式開發更容易且更簡潔有效率。如諧音『 G.Lib - 就是.懶』,將它說是應用程式開發者的『懶人包』,可是一點也不為過呀。

Glib Utilities 中有個函式包裝『GKeyFile』,此包裝提供一個存取設定檔的界面,讓程式開發者不再需要為了讀取設定檔,而被迫自行撰寫許多程式來處理檔案資料流和分析設定檔,是個非常省時省力的函式包裝。

GKeyFile 存取的設定檔,就是一個 .ini 檔的形式,大致上像:
[group1]
mykey1=66
mykey2=Hello World

[group2]
yourkey1=yes
yourkey2=3.1415926

想使用 GKeyFile 撰寫程式讀取並顯示設定檔的內容,程式碼如下:
#include <stdio.h>
#include <glib.h>

void main(void)
{
GKeyFile *keyfile;
GKeyFileFlags flags;
GError *error = NULL;

/* 初始化 GKeyFile */
keyfile = g_key_file_new();
flags = G_KEY_FILE_KEEP_COMMENTS | G_KEY_FILE_KEEP_TRANSLATIONS;

/* 讀取 config file */
if (!g_key_file_load_from_file (keyfile, "helloworld.conf", flags, &error))
return;

/* 讀取設定並顯示 */
printf("[Group1]\n");
printf("mykey1: %d\n", g_key_file_get_integer(keyfile, "group1", "mykey1", NULL));
p…

使用 C 語言做『梯型法則』積分運算

『梯型法則 Trapezoidal Rule』是積分方法的基本定理之一,從高中到大學的數學課程中都有提到,碰到工程這種需要大量求值的領域,我們就必需將這些積分方法寫成程式。

詳細程式碼:

#include <stdio.h>
#include <math.h>

double my_eq_orig(double x)
{
return 0.2 + 25*x - 200*pow(x, 2) + 675*pow(x, 3) - 900*pow(x, 4) + 400*pow(x, 5);
}

double my_eq(double x)
{
return -400 + 4050*x - 10800*pow(x, 2) + 8000*pow(x,3);
}

double integrate_trapezoidal(double (*fx)(double), int n, double a, double b)
{
int i;
double h;
double x = a;
double s = 0;

h = (b - a) / n;
for (i=1;i<=n-1;i++) {
x += h;
s = s + fx(x);
}

return h * ((fx(a) + fx(b)) / 2 + s);
}

void main(void)
{
/* real */
double real = integrate_trapezoidal(my_eq_orig, 100, 0, 0.8);
/* n = 1 */
double real_i = integrate_trapezoidal(my_eq_orig, 1, 0, 0.8);
/* average */
double fa = integrate_trapezoidal(my_eq, 100, 0, 0.8) / 0.8;

printf("real value:\n%lf\n\n", real);
printf("I:\n%lf\n\n", real_i);
printf("f(x)\'\' average:\…

一朝被蛇咬,十年怕草繩

圖片
這幾個月,感謝朋友和網友們的幫助,施於我的案子,多到我都不知該如何分配時間去接,其中又要騰出時間兼顧對『自由軟體』的喜愛,實在累人呀。曾幾何時,我也慢慢變成了專職的『工讀生』,如 Jserv 所說:『我只是工讀生,沒有受過高等教育。』尚未畢業的我,對這句話特別有感。

滑鼠隨筆
許多案子,在談的過程中,通常是充滿愉快,這代表案件將可能很順利成交,大家各取所需,互不相欠。不過,談雖愉快,往往問題都出現在合約上,以致簽署的過程中並不是這麼的順利。由於家裡背景的因素,至今就算我沒簽過太多合約,也經手過無數的合約,其中一時疏乎衍生出來的斃端,更是曾讓我受過不少教訓,逐漸對簽約這件事『龜毛』了起來。由於『一朝被蛇咬,十年怕草繩』的緣故,我盡量避免簽龐大的合約,轉以各種較小文件的簽署總合做替代,一方面避免大合約的疏忽造成問題,另一方面可以明確知道做了多少事,又該有哪些相對應的回報。

當然很多事還是得用一份完整的大型合約決定,但這總是讓我傷透腦筋,因為處處可見其斃端,稍有不慎,雙方都沒保障。日後要是打起官司來,耗時耗力又傷和氣,那才真的是無奈。