聚會時間公告: 因應COSCUP 2011, Kalug 8月份休會一次

五月 13, 2016
» 3GPP Public Warning System (PWS) in ofono

The Taiwan government has launched the new Public Warning System to warn cell phone subscribers the happening emergency. There are a few integration need to be done to support PWS on Ubuntu phone.

  1. rild from Android.
  2. ofono to dbus.
  3. User interface to handle the dbus event.

ofono supports the CBS/PWS[1] long time ago. There are a few TODOs to support the PWS

  • Make sure the rild can receive and pass the Cell Broadcast Service (CBS) to ofono
  • Need a userspace program to handle the Emergency Broadcast from dbus.

References:

[1] 國家通訊傳播委員會_災防告警系統(PWS)介紹 – http://www.ncc.gov.tw/chinese/gradation.aspx?site_content_sn=3744
[2] ofono/ofono.git – Open Source Telephony – http://git.kernel.org/cgit/network/ofono/ofono.git/tree/src/cbs.c#n100
[3] PWS specs

  • PWS – Public Warning System – https://tools.ietf.org/agenda/79/slides/atoca-0.ppt
  • 3GPP specification: 22.268 – Public Warning System (PWS) requirements – http://www.3gpp.org/DynaReport/22268.htm
  • 3GPP specification: 23.041 – Technical realization of Cell Broadcast Service (CBS) – http://www.3gpp.org/DynaReport/23041.htm
  • LTE for Public Safety – Rainer Liebhart, Devaki Chandramouli, Curt Wong, Jürgen Merkel – Google 圖書 – https://books.google.com.tw/books/about/LTE_for_Public_Safety.html?hl=zh-TW&id=oVy3BgAAQBAJ

The post is based on engineering note.

五月 7, 2014
» 使用 Ubuntu 14.04 電子申報綜合所得稅

已經連續兩年都只用 Ubuntu/Firefox 申報稅務,雖然界面醜陋,使用經驗很糟糕。但是財政部算是努力支援不同的作業系統,今年甚至開始支援 Android Tablet 版本的電子申報程式

在 Linux/MacOS 上,你可以用網頁 Java Applet 版本的綜合所得稅電子結算申報繳稅系統網站 進行結算申報,這個系統大部分都是以 Java 完成,跨平台相容性頗佳。但如果你需要使用自然人憑證登入,需要額外安裝中華電信自然人憑證用戶端元件,這個元件使用 Native extension,跟往年一樣,只有支援 x86 版本。

根據 Ubuntu Popularity Contest 統計資料,amd64 (64 bit) 的使用者已經超越 i386 (32 bit)  使用者了。只支援 x86 ,代表使用者必須重新安裝一個新的作業系統才能正確執行自然人憑證用戶端元件。

去年,為了自然人憑證用戶端元件只支援 amd64 以及版次只支援舊版 Firefox,我發了信聯絡 HiPKI客服中心以及 關貿網路電子申報繳稅客服中心,收到兩封郵件

HiPKI客服中心: 關於綜合所得稅電子結算申報繳稅系統是由財政部委託關貿網路股份有限公司製作,若有使用上之建議請向財政部反應。

關貿網路電子申報繳稅客服中心: 客服中心已記錄您的建議事項,並反應給技術團隊,若造成您的困擾,敬請見諒!

 

沒有解決方案,最後是自己硬升級一包 Firefox extension 解決版次問題。至於 i386 只好建一個新的 Ubuntu 來安裝了。 希望來年可以直接支援 amd64 版本。另外今年的 irc.jar 裡面沒有不小心放進去的 .java.bak 檔案了。 (茶)

sbuild

在 amd64 環境安裝一個新的 i386 Ubuntu 有很多種方法,基本的工具是 debootstrap。 在 Ubuntu/Debian 中有不少工具可以協助你建立環境。我習慣用 sbuild / schroot ,這兩套平常當作編譯環境,但是借來快速建立 chroot 也非常方便。

最快速的方法,是用 mk-sbuild 設定一個新的環境,以下例子為建立一個 i386 的 trusty (14.04 LTS) Ubuntu chroot.

apt-get install schroot sbuild ubuntu-dev-tools pcscd
SCHROOT_PROFILE=default mk-sbuild --arch=i386 --debootstrap-include=firefox,fonts-unfonts-core,fonts-droid,openjdk-7-jre,icedtea-7-plugin --distro ubuntu trusty

完成之後,你可以用 schroot -l 來列出有哪些 chroot

$ schroot -l
chroot:trusty-i386
source:trusty-i386

接下來你需要更改預設的 profile 設定,檔案在 /etc/schroot/default/fstab 。請加入以下兩行,這是讓你在 schroot 中可以存取原系統中的檔案。其中 /var/run/pcscd 是 pcscd 的目錄,是系統用來接取自然人憑證用的。

/home        /home        none    rw,bind        0    0
/var/run/pcscd    /var/run/pcscd    none    rw,bind 0 0

注意 schroot -l 出現兩個名稱。你若使用 chroot:trusty-i386,系統會用 LVM snapshots 或 unions 建立一個暫時的環境,所有的改變都會在登出後遺失。所以你若需要更改 schroot 中安裝的的程式,請使用 source:trusty-i386.

sudo schroot -u root -c source:trusty-i386

若是一般使用者用途,則只需要

schroot -c chroot:trusty-i386

接下來即可執行 Firefox, 由於我們在兩個不同的系統間共用家目錄。我建議另外開一個專門的 Profile ,事後會比較容易清理。

DISPLAY=:0.0 firefox -no-remote -ProfileManager

接下來你就有一個在 i386 中執行的 Firefox 可以使用了。

這篇文章使用的軟體版本為


Ubuntu 14.04
debootstrap    1.0.59ubuntu0.1
firefox    29.0+build1-0ubuntu0.14.04.2
pcscd    1.8.10-1ubuntu1
sbuild    0.64.1-1ubuntu4
schroot    1.6.8-1ubuntu1
ubuntu-dev-tools    0.153

延伸閱讀

二月 11, 2014
» apt-cacher-ng

養了很多 Debian/Ubuntu 機器時,時常得利用 apt 大量更新軟體。最常見的需求是 Security updates,所有伺服器都會抓取同一份軟體,機器量一大用掉的頻寬也很可觀。為了省下這些頻寬,得在伺服器區域網路設定一組快取伺服器,讓全區域網路下載一次。

有得人會自己建一份 archive mirror.

但是 Debian/Ubuntu 套件眾多,全部映射一份實在很費空間。我個人偏好只快取曾經抓過得檔案。

Debian/Ubuntu 中已經有幾個選項可用
approx – caching proxy server for Debian archive files
apt-cacher – Caching proxy for Debian package and source files
apt-cacher-ng – caching proxy server for software repositories
apt-p2p – apt helper for peer-to-peer downloads of Debian packages
debtorrent – bittorrent proxy for downloading Debian packages
apt-transport-debtorrent – an APT transport for communicating with DebTorrent
squid-deb-proxy – Squid proxy configuration to optimize package downloads
squid-deb-proxy-client – Automatic proxy discovery for apt based on avahi

其中 apt-p2p 與 debtorrent / apt-transport-debtorrent 是大約 2006-2008 年 p2p 技術熱門時的嘗試。而 debtorrent 直接利用 bittorrent 協定,而 apt-p2p 使用 kademlia DHT 協定來處理分散檔案,需要安裝 Twisted. 兩個概念都很有趣,但是我並不想在每台機器上架設 p2p server,純粹只是需要供應新的安裝檔案。

個人評估之後,選了 apt-cacher-ng. 設定簡便,apt-get 安裝完即可用,不相依於其他網站伺服軟體。還有簡易的管理界面可以看快取效率唷!

由於它基本上是個 http proxy,所以你可以用 transparent proxy 來導引所有的下載,或者在 /etc/apt/apt.conf.d/90aptcacher-ng 加入以下設定即可。
Acquire::http { Proxy "http://10.11.11.254:3142"; };

除了可以透過預設網頁來看快取狀態,也可以在 console 跑 /usr/lib/apt-cacher-ng/distkill.pl 來看硬碟上佔用了多少空間。

References

AptProxyCache – Ubuntu Wiki https://wiki.ubuntu.com/AptProxyCache

apt-cacher-ng

apt-cacher

approx

DebTorrent

apt-p2p

AptProxy

十一月 18, 2011
» 第一次 Ubuntu Developer Summit 經驗

十一月初的時候,到 Orlando, FL 的 Caribe Royale 出席參加 12.04 的 UDS-P – Ubuntu Developer Summit. Ubuntu 開發者大會。

UDS 是每半年一次的研討會,每次都會邀請各「上游」社群與 Ubuntu 開發團隊聚集在一起,討論下一版的主要開發目標並制定里程。而 UDS-P 的主要議題,自然是下一版 12.04 的 Precise Pangolin (嚴謹的穿山甲),12.04 也是 LTS 版本,支援期間長達五年。也因此 Mark Shuttleworth 也在開場 Keynote 的時候鼓勵與會者,在場的一言一行都會受到世界許多關注,在長達一週的會議中,所做的決定都會影響到許多使用者 (目前 Ubuntu 有超過兩百萬使用者),特別是偏好穩定系統的企業。

UDS 的形式有別於一般「研討會」,會場總共有 24 間會議室 (本次跟 Linaro Connect Q4.11 合辦),除了少數幾個全場演講是以簡報演講方式進行,剩餘大部分的議程是由註冊人帶領,幾位主要的開發者以圓桌方式坐在會議室中央,其他人可以隨意進入旁聽,並隨時插入相關議題或提問。像是 Multi-monitor Support 等熱門議題,太晚進會議室只好待在後面站著囉。

議題內容多元,從社群經營硬體核心基礎軟體雲端系統中國版本,甚至是發想性質的議題,像是讓 Ubuntu 支援手機、平板電腦與智慧電視裝置 等等。每個議題時間大約一個小時,各個來自世界各地的開發者,在大量咖啡因的作用下,進行節奏迅速的爭辯討論。由於並非每位開發者都可以現場出席會議,遠端開發者也可以透過即時語音廣播 (icecast) 與 IRC 加入討論。

costume party_831

一個小時的會議後,所有的討論會整理成藍圖 (blueprints),這些藍圖就是本次發行階段所需要開發的目標項目與負責人。在 UDS-P 中,有超過三百份藍圖。這些藍圖完全透明開放給所有人參考,也歡迎任何人介入制定。

許多開發者,即便是 Canonical 員工,有超過 70% 都是在家中工作,UDS 是難得的難得可以相互見面的機會。各個上游軟體專案的開發者,也會出席這次的會議,像是 Debian Project Leader Stefano ZacchiroliFreeRDP Marc-André Moreau 等等。他們增強了 Ubuntu 與上游專案進一步的合作關係。

令人印象深刻的是,整場會議中許多強者對於其他人的開放信任態度,記得在週四晚上的 Keysigning Party,我身旁一位 “神級” Debian Developer,誠懇對每一位交換簽章的人,說「沒問題,我相信你」,也許是因為大部份的人都抱持一樣的態度,使會議進行相當順暢而且充滿生產力的歡樂氣氛。

costume party_981

接下來還有力氣的話,我會再分享一些議程資訊。

照片: http://www.flickr.com/photos/37955218@N08/sets/72157627962230661/
訪問: http://akgraner.com/?p=1124
錄影: http://www.youtube.com/user/ubuntudevelopers#p/u

Ubuntu UDS P Orlando – Interview with Mark Shuttleworth

利益揭露: 筆者為 Canonical 員工。

七月 18, 2011
» 如何與開放原碼社群合作

參與開源社群活動時,常常在不同的場合聽到有人鼓吹,應當要回饋自己的時間與精力給軟體計畫,講者要求大家去參與翻譯、籌辦活動、或參與開發。每每聽到這種要求,總是感到納悶,常常他們似乎都未能夠分享實際參與社群的動機,二來總是有種道德勒索的錯覺。他們暗示你,這麼好用的軟體不收你錢,你該回饋些什麼吧?

雖然我相當崇尚自由軟體精神,但是實質上,無法接受不談動機,反以道德訴求要求使用者社群貢獻來回饋免費軟體。人們參加開放原碼社群的動機很多樣,無論是功利主義還是榮譽制度,負面的道德勒索往往不該是其中的一項。對我而言,這個動機實際一點就是讓自由軟體更便利好用,足以完成手上的工作項目。長遠一點的期望則是鼓吹開放精神,避免電腦軟體受到少數企業集團、政治組織的宰制,讓社會更自由且多元化。

週末 (7/15-7/18) 時,h4 的朋友參加 OSSACCOSSF 籌備的 Hacking Camp,講者小蟲在他的演講中分享了幾個基本概念

  • Hacking for yourself
  • Hacking without boundary
  • Hacking with community
  • Hacking with for fun

我個人十分認同,h4 日常的聚會討論,時常是針對每日所使用的軟體改進、臭蟲回報修正,進而整合或重新設計新的軟體。Hacking 首重解決自身需求以及享受其中的樂趣。

我在 Hacking Camp 也分享了一場小演講,想要探討的是,如何考慮自身軟體需求的前提下,參與自由軟體計畫的方法。雖然目前自由軟體的成熟度與日俱增,但仍有許多時候會碰到使用上的問題,這份演講簡報,試圖說明該如何詢問問題,該如何回報臭蟲,以及如何與上游開放原始計畫互動,以便解決個人的使用障礙或達成開發目標,針對對象是大學資工系一、二年級的朋友。

五月 30, 2011
» Linux 上處理壞軌硬碟的兩三事

養動物園或是管理伺服器的人,難免都會碰到一些硬碟故障的問題。這篇文章略為整理一些在 Linux 上處理壞軌硬體的一些軟體知識與技巧。針對讀者為中等程度以上的使用者,文中僅僅提供參考資料,不說明實際操作或指令明細,請自行參考相關文件。作者以最大善意盡力提供參考資訊,但文中如有疏漏或錯誤造成資料遺失,作者不負任何責任。

文中說明均以 Linux Extended file system 為主,操作平臺是 Debian GNU/Linux. 所提及工具授權均為 FLOSS 。假設錯誤硬碟為 /dev/sdb,所有指令需要以 root 執行。

章節結構

  • 錯誤類型。
  • 壞軌測試。
  • 預先偵測。
  • 備份與資料回復。
  • 排除壞軌磁區。
  • 送修與資料清除。

錯誤類型

這裡討論的硬碟資料損毀,不外乎物理性傷害,摔落、靜電、停電、過熱、原件老化等等。這些傷害會造成邏輯性 (logical error) 上或物理 (physical error) 性的錯誤。

所謂的邏輯性錯誤,就是硬碟離線時,暫存資料來不及寫入,導致資料錯誤異常。所幸大部分的檔案系統都會有一個檔案系統狀態 (Filesystem state) 的值,若是最後使用未順利完成卸載 (umount),下次掛載時就會提示要求作 fsck 檢查。如果是日誌式檔案系統ext3/ext4,則會試著回復未完成的操作。這種錯誤偶爾會破壞檔案,fsck/e2fsck 可能會將錯誤檔案移到 lost+found 目錄下,造成困擾,但問題不大。

物理性錯誤指的是硬體磁盤受到損壞,該段磁區無法讀取,也就是壞軌。肯定導致資料遺失,最常見的是系統吐出 I/O Error,無法讀取該檔案。實際的症狀是讀取變慢、聽到 Spin-up 時的卡卡聲(Clicking sound),甚至是系統當機等問題。

當壞軌開始產生時,通常代表硬碟壽命將至,得趕快開始更換健康新硬碟。這篇文章主要討論的是壞軌這種物理性錯誤的處理辦法。

壞軌測試

最基本的測試方法是利用 badblocks (8) 來檢測硬碟是否存在壞軌,這個指令不分檔案系統。若是含有重要資料的硬碟,應該先作預設的非破壞性唯讀測試 (non-destructive read-only test),以避免寫入測試時異常,造成磁碟重置離線。

badblocks -vs /dev/sdb

上述只要一發現壞軌,請第一時間拔下備份吧。若是可承受資料損失,可以使用 “-n” 的非破壞性寫入式測試。這基本上會嘗試寫入資料,再三確認硬碟運作正常。

badblocks -nvs /dev/sdb

預先偵測

不過 badblocks 需要在離線時才能執行。很多時候,伺服器是無法忍受長時間的離線檢查的,必須要能夠線上檢測硬碟健康狀況才行。目前市面所有 ATA 硬碟都已經支援 S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology),S.M.A.R.T.  基本上提供一個界面讓管理者可以查詢幾個重要的參數

透過讀取這些參數,管理者能夠預先警覺硬碟錯誤。根據 Google 的調查十萬顆硬碟後的研究報告 (Failure Trends in a Large Disk Drive Population),S.M.A.R.T. 的數值的確反應硬碟錯誤率 – 六十天內,出現 S.M.A.R.T. 掃描錯誤的硬碟是其他硬碟的 39 倍高。

在 Linux 上,可以使用 smartmontools 中的 smartctl (8) 來查詢硬碟的 S.M.A.R.T. 狀態。指令如下

smartctl --attributes /dev/sdb

根據 Google 的研究以及 Bad block HOWTO for smartmontools 指出,與硬碟失效關係最高的數值是 Reallocated Sectors Count/Reallocations event count, Current Pending Sector Count, Uncorrectable Sector Count。這幾組數據代表硬碟發現該磁區已經損毀,它會重新從備用磁區分配一位置取代該損壞磁區,或磁區已發現問題尚未替換或無法替換。這通常可以視為磁區損耗 (surface wear) 的狀況。當你發現這些值不為 0 時,就該開始準備備份資料並作壞軌檢查了。

除了使用 smartctl 手動檢測外,也可以設定 smarted,讓系統自動觀測 S.M.A.R.T. 狀態,有錯誤會顯示於桌面訊息或發送郵件。smartd 的設定可以參考 檢測硬碟狀態 – smartmontools 一文。S.M.A.R.T. 也支援 Self-Test,可以讓硬碟作效能與功能檢查,詳情請見 smartctl (8).

備份與資料回復

在發現壞軌之際,應該第一優先備份資料。如果還能夠掛起檔案系統,則趕緊利用 rsync, tar 等工具備份檔案。或者利用 dd 將整顆硬碟資料或分割區存檔,未來置換到新硬碟上

dd if=/dev/sdb of=sdb.img

若要確保資料正確複製,可使用 dcfldd 來複製,它會邊複製邊作 hash 確保資料複製正確。不過由於壞軌處常常無法讀取,這會造成 dd 執行失敗。此時可以改用 dd_rescue, 它可以略過無法讀取的部分,儘可能複製其他健康的資料。

不過天有不測風雲,人有旦夕禍福。萬一資料損壞的區域不是資料區域,而是存放重要的系統資訊,那就需要額外的處置。建議無論任何時候,都不要在壞硬碟上直接操作,永遠先備份,再於備份碟上進行處理。以下略談三種情境的可用工具

排除壞軌區域

通常如果你的硬碟還在保固範圍,一般原廠均會更換健康的硬碟給你。但如果硬碟已經超過保固,壞軌硬碟仍堪用,可以用來存一些低度重要的資料。

對於這些壞軌,可以用 sector slipping 或叫做 defect mapping 的機制來跳過不用。基本上分成兩種形式,一是透過硬碟控制器或是透過檔案系統的 bad block table 來記錄。

傳統的 (1990 年代中期以前的硬碟)是可以進行低階格式化 (Low-Level Formatting) 的,透過原廠的指令來重新定義物理儲存格式、重新定義 CHS、若是硬碟中有壞軌,可以在低階格式化時避開不用。

由於低階格式化常因為操作錯誤而損壞 (bricked) 硬碟,新款硬碟已經不提供使用者透過指令作低階格式化的工具。取而代之的是透過 hard-drive defect management 功能,以 Hard drive defects table – P & G Lists 來記錄 Bad Sector Mapping。所謂 Primary defect list 是代表出廠時已經產生缺陷的磁區列表,而 Grown defect list 則是使用中產生缺陷的磁區列表。

當硬碟發現壞軌時,便會自動將該磁區列入 G-List 中,並從備用的磁區中替換。因此現在已經沒有所謂低階格式化,目前所謂低階格式化大多指的是 Zero-filled,對磁區填入空值,強迫硬碟重新分配損壞磁區,這也是前述 S.M.A.R.T. 所謂 Reallocated Sectors。

所以你可以做的事情是對壞軌區域寫入空值,迫使它重置。你可以直接透過一開始的 badblocks 所產生之數值直接覆寫錯誤區塊,範例請見 Bad block HOWTO for smartmontools

上述 HOWTO 中詳述了,怎麼計算 e2fsck 吐出來數值,人工計算有點麻煩。以下介紹如何處理利用工具自動處理。

不保留資料

如果確認整顆硬碟資料都不需要保留,可以直接下達一下 dd 指令,重寫整顆硬碟。

dd if=/dev/zero of=/dev/sdb

或者在格式化時下達 -c -c 參數,讓 mkfs.ext3 順便檢查壞軌。

mkfs.ext3 -c -c /dev/sdb1

保留資料

如果硬碟已有資料,並想保留此資料,可以用 badblocks 檢查,並生成 badblocks list,再將 badblocks 吐出的列表,餵給 e2fsck -l.。但是必須確認執行 badblocks 時,指派了正確的 block size,可用 dumpe2fs -h 確認 block size.然後指示給 badblocks。

上述操作有點複雜,比較保險的做法是直接讓 e2fsck 用 badblocks 去作壞軌檢查,指令如下

e2fsck -k -c  -c /dev/sdb1

如此 e2fsck 會將壞軌寫入檔案系統列表中,可以用下述指令查詢目前壞軌列表

dumpe2fs -b /dev/sdb1

其他做法

本節前述可用低階格式化重置硬碟磁區分配,但是新款硬碟已少提供工具程式給終端使用者。有些工具透過反組譯硬碟韌體的方式取得 vendor specific ATA commands。另外,像是 Seagate 等品牌,則在硬碟上留有 TTLserial communication界面,於是你可以透過終端機連上硬碟韌體,以 Diagnostic Commands 進行一些偵錯以及重新格式化的動作。

送修與資料清除

爲了避免陳冠希裸照事件發生,送修前最好確保資料已經完全刪除。

就如前述所說,若只是進行快速格式化,硬碟資料也可能被回復。事實上,根據 Peter Gutmann 的在 90 年代的研究,他可以用磁力顯微鏡取得複寫過三十五次以上的磁區資料。而美國 National Institute of Standards and Technology 的研究 “Guidelines for Media Sanitization” Craig Wright, Dave Kleiman, Shyaam Sundhar R.S. 的論文 Overwriting Hard Drive Data: The Great Wiping Controversy 指出,新型硬碟只需要複寫一次即可。

爲了達到資料保密措施,各國軍方也因此設定有不同的資料清除 。總之,無論你的資料是否重要,在 Linux 上,建議使用這兩種 wipe, scrub 指令之一來抹除資料,這兩種工具支援上述的各國標準。你也可下載使用 DBAN 製作開機片來清除硬碟資料。

References

五月 20, 2011
» PGP Key transition (DC76FEB9 -> 3860D2A5)

I should replace my key long time ago, after there are security flaws has been identified in SHA-1. The US NIST also suggested to transit to stronger SHA-2 hash functions.

I followed the key replacement rules of Debian and Apache and created the new key. If you have validated my old key, Here is my transition statement for the new new 4096 bit RSA key -

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA512


I am transitioning GPG keys from an old 1024-bit DSA key to a new
4096-bit RSA key. The old key will continue to be valid for some
time, but I prefer all new correspondence to be encrypted in the
new key, and will be making all signatures going forward with the
new key.

This transition document is signed with both keys to validate the
transition.

If you have signed my old key, I would appreciate signatures on my new
key as well, provided that your signing policy permits that without
reauthenticating me.

The old key, which I am transitional away from, is:

pub   1024D/DC76FEB9 2004-09-18 Rex Tsai 
 Primary key fingerprint: 1700 7040 CBD7 5DB4 4956  959B 3A5E 166D DC76 FEB9

The new key, to which I am transitioning, is:

pub   4096R/3860D2A5 2011-05-20 Rex Tsai (蔡志展) 
 Primary key fingerprint: CDC8 966D A547 6B1F CEB8  6D49 86A6 03D4 3860 D2A5

To fetch the full new key from a public key server using GnuPG, run:

  gpg --keyserver keys.gnupg.net --recv-key 3860D2A5

If you have already validated my old key, you can then validate that the
new key is signed by my old key:

  gpg --check-sigs 3860D2A5

If you are satisfied that you've got the right key, and the UIDs match
what you expect, I'd appreciate it if you would sign my new key.

If you then want to sign my new key, a simple and safe way to do that is
by using caff (shipped in Debian as part of the "signing-party" package)
as follows:

  caff 3860D2A5

In the other way, you can sign the key and send it to me as following 
commands:

gpg --sign-key 3860D2A5
gpg --armor --export 3860D2A5 | mail -s 'OpenPGP Signatures' \
        chihchun@kalug.linux.org.tw
gpg --keyserver pgp.mit.edu --send-key 3860D2A5

Please contact me via e-mail at  if you have
any questions about this document or this transition.

Thanks.

Regards
Rex Tsai, 2011-05-21
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3WnNEACgkQOl4Wbdx2/rnujQCbBV+TSHWapsMrd5d06RKxkgT3
csUAnRpDr6obff4Fuj/P530f6pVT5WTXiQIcBAEBCgAGBQJN1pzRAAoJEIamA9Q4
YNKldvgP/2ej6EDhrGj/1dNkIdkWmKNXsj4OMWKcvDP6M+VnlkWtFaDQxYBb73Ea
vBhAgDZL7MhUwVbn9zydVInFpA9vtdsBwd6Hr3+rp+iv076TennKYP+qo7YDX5Ga
7s73Tim8Tn6AwYdBhyhFPJPZ/fEUknKNOWILu7eUjeQ+C7ndPNEe6VRvCJvJaHwa
aJ6b8kpeRG6UYQFGw/o2e0XGtEpek8dRiqk2sVnOVR/d0C6/u+2oQuGRVtX/uKd1
2E3HYPh/Y1RTqENYrCd39v8nA6NUzuw8kOpIx8MZ51iN4DB+YfusV8mtzhZIkVQP
y2BZ0jL2C2xFlCER7Cxlp8VpsKcz/tEixytciC0aOuoUoER7LQvfkQGs+pcTj8Fl
PQLmwgnqIM4PPQ4cSyhsFgmSkbFcDyxtStVLMEtJKKAJ0dOuqa13R0MKuRkg5WMP
u07EKBITk50QlqzXrJwM7I8FszIigbdWWQD2qNbXLpHcZNo5m5CshOVgTCy+t7E4
Z0gQ3DnZAsy+tclCjCeb6MdjRqF27C9LdWjNwHHcw71X2yqRXqEN8fb1JcXBSU5a
7AgiIMnDgw3BAm1QLQ/eEk8J7KuKvsFFK+hFpSs4mahYLUtExzSsEN7RbCQptSIc
4FfZUXS3bg+by4zF/2eSGI+FeMq7CIz4aX1JdfucBiFCNUCRhFPT
=kr5F
-----END PGP SIGNATURE-----

五月 16, 2011
» Linux 系統軟體開發書籍推薦與 TLPI

記得 2006 年 chroot/Hacks in Taiwan Conference 的發起人 timshu 曾經出版過一書 《Linux C函式庫詳解辭典》,這本書含括了超過 400 個函式,成為許多 Linux 軟體開發者的參考手邊書。

雖然 Linux/Unix 系統上有相當多的參考文件,只要你知道該問什麼問題,都可以找到答案。但是線上手冊 (man pages, info)常缺乏系統式的整理,新手頗難入手。且 man pages 有時言簡意賅,缺乏範例程式,往往不容易閱讀。因此像是《Linux C函式庫詳解辭典》便極有參考價值。

類似的系統 API 書籍還有 Robert LoveLinux System Programming: Talking Directly to the Kernel and C Library。rlove 的書對於各系統層廣度足夠,可惜深度不足,書中充滿提示,你得有足夠的背景知識纔全然理解他所要傳達的資訊,而具體的實務應用資訊也不足,無法用來當作字典臨時查詢需要的 API 與範例。

2010 年十月,Michael Kerrisk 發表了 TLPI – The Linux Programming Interface,Michael Kerrisk 是 Linux man-pages Project 的維護者,文件維護者出書其份量與內容勢必可觀,TLPI 內容超過 1500 頁、超過 60 個章節、超過 200 個範例,內容除了含括 POSIX.1-2001/SUSv3POSIX.1-2008/SUSv4 外,也包含了許多 Linux 獨有的特色,對於跨 UNIX 作業系統移植性亦有著墨,相對於 Richard Stevens 與 Stephen A. Rago 的 Advanced Programming in the UNIX Environment ,圖表與內容均不遜色,且每個章節都至少有一題練習題。

值得一提的是,TLPI 除了介紹 system calls 外,文中也試著說明 2.4.x. 到 2.6.x (2.6.34) 間核心變動對於系統的影響。

推薦 Linux 軟體開發者備妥一本作為案頭書。

五月 11, 2011
» Wine 對於硬體驅動程式的支援

硬體支援概況

在 Wine 中接取硬體,主要有兩種模式。

一、直接介接 Linux 的 API,像是 X11, SANE, V4L, ALSA 等等。目前少數實做的硬體介接模擬功能有圖形 (winex11.drv, winequartz.drv) 、音效以及輸入裝置 (keyboard, mouse, joystick, twain/sane) 等模擬層。另外 Wine 提供了 IoCode/Operation Code 轉譯功能,容許 Windows 程式直接存取硬體,這包含 Serial Communications[2] 以及 CDROM/ATAPI, TAPE 支援。

二、另外一種則是類似 NdisWrapper,直接載入並使用 Windows 驅動程式。目前而言負責載入 Windows 驅動程式的 NTDLL 中均未實做 NtLoadDriver, ZwLoadDriver 等函式細節,只宣告為 Stub Function. 因此即便驅動程式安裝程式可以順利安裝、註冊相關驅動程式 DLLs, Wine 也不會載入這些驅動程式。

目前 Wine (1.3.19) 並沒有模擬載入底層驅動程式

Smart Card Support

Smart Card 支援問題是最常被詢問的問題之一,依據 MSDNSmart Card Subsystem 設計,可以分為以下數層

  • Smart Card Service Providers
  • Resource Manager
  • Specific Smart Card Reader Driver
  • Smart Card Reader Helper Library

驅動讀卡機是最基本的功能。參考 Microsoft Class Drivers for USB CCID Smart Cards結構說明,驅動程式有兩類,一是 CCID 相容硬體或 USB 廠商所提供的驅動程式。而其上應用程式可用 Smart card resource manager (winscard.dll) 來下達 PC/SC 指令。

如上所述,Wine 並不會載入驅動程式。winscard.dll 目前也只是 stubbed functions.

不過 IDRIXMounir IDRASSI 開發了介接 PCSC-Lite/pcscd,使 Smart card resource manager 可以透過 PCSC-Lite 提供 PC/SC Services.

USB Support

理論上,user-mode 的 USB 驅動程式也可以透過轉譯直接存取 USB 設備,只要該軟體未使用 ntoskrnl.exe, hal.dll, usbd.sys 以外的功能。目前官方 Wine source tree 只在 usbd.sys 中實做查詢 USB Devices 功能。

Etersoft 的 Alexander Morozov 則已利用 libusb 實做 USB 功能,提供一些需要使用 USB hardware token 進行硬體保護的軟體使用。這些功能未整合到 Wine 主程式。相關程式碼位於 ftp://ftp.etersoft.ru/pub/people/amorozov/usb,使用時需要手動在 registry 中加入 vendor id/product id 設定

四月 10, 2011
» 遺失的時代精神 – Zeitgeist and GNOME Activity Journal

這是 2011/04/09 為了 GNOME 3 Launch Party 臺北場 所準備的演講。

Zeitgesit 與 GNOME 其實一年前就曾經在 blog 上介紹過。這次的演講主要是想談 GNOME 2 到 GNOME 3 開發者對於增進 UX 的典範轉移。過去十年來,GNOME 計劃雖然強調 UsabilityAccessibilty,但始終在使用者界面中以大量的隱喻來協助使用者應用電腦系統,追隨著主流圖形化界面的影子。

直到 GNOME 3 中的 GNOME Shell 計劃,開發者開始思考當下這個世代人們在資訊系統上的困境,而對問題的重新定義,進而發展新的方向。而我試著討論除了 UX 以外,GNOME 計劃想解決的問題,重新審視人對於工作方法、記憶的使用方式。稍加提到目前 Linux Desktop / GNOME Project 可用的軟體。並再從記憶使用的觀點,進一步介紹 Zeitgeist 的想解決的問題,以及它的軟體架構與相關計劃。

簡報檔可於 SlideShare 下載

備註: 遺失的時代精神是因爲 Zeitgeist 與 GNOME Activity Journal 要在 GNOME 3.2 纔會納入 GNOME Project.

四月 7, 2011
» Wine – 在 Linux 中使用 Windows 程式

簡介

自從 Wine 1.0 2008 年六月釋出之後,便開始以兩、三周為週期,開始固定的釋出新版。Wine 是針對 POSIX 相容的作業系統所設計,目前 Wine 已經被移植許多平臺上,除了 Linux 外,也可以在 Solaris, FreeBSD, x86 版本的 Mac OS 上使用。經過長期的開發與社羣支援,目前在 Appdb 中已有超過一萬六千個軟體測試報告,其中有將近 3000 筆是屬於高度可用 (Platinum List) 的軟體。

在 Appdb 中仍有大量的軟體存在執行的問題,造成使用困擾,甚至無法使用。這與 Wine 的設計有關,Wine 跟 Dosboxzsnes 不同,既不是模擬器,也不是虛擬機器。它是以軟體方式模擬出 Windows® 作業系統所需的軟體架構 (Software Stack),理論上只新增一層 software layer 會比虛擬化成本低廉。

雖然 Wine 計劃經過十幾年發展,但是市面上目前為止沒有任何書籍介紹 Wine 及其程式架構,開發者只能參考少數幾份線上文件Wiki 來理解 Wine 的程式架構。本文稍加介紹 Wine 的相關設計。

軟體架構與初始化簡介

根據 Wine Developer’s Guide,軟體架構如下

要在 UNIX 中模擬一個 Windows® 作業系統,有許多差異需要克服,且 Wine 為了開源授權的合法性,並不對 Windows® 本身進行反組譯,而是用黑箱測試法所開發出來,並參照開發文件逐步實做所有的 Win32 APIs。問題在與 Win32 API 文件並沒有完全開放,不同版本作業系統間,也有些微行為上的差異。然而 Windows® 有著為數不少缺乏文件的 APIs. 甚至錯誤的 API 反應等等,Wine 都需要一一的實踐。加上仍有一些未開放的低階 API,以及一些缺乏文件的協定或設計,Wine 計劃可以說是以血淚走過來的開發工作。

以 Wine 模擬 Windows® 最重要的功能之一就是 Wine server, 它基本上是提供作業系統核心模擬的功能,負責 Inter-Process Communication (IPC), synchronization 與 process/thread management 等等工作。Wine server 是一個獨立的程序,每次啟動任何 Windows 程式前,它會優先被叫起。若出現了什麼問題,也要確保砍掉 (kill) 它後,才能乾淨的重新執行。

而在 Wine preloader 載入 .COM / NE / DLLPE 前,由於每個程序都將使用自己的記憶體空間,Wine 要先依照不同的執行檔格式需求建立 Memory layout,為了能夠在 Linux 中製造出跟 Win32 一樣的記憶體位置,除了試圖將相關的 DLLs 載到正確的記憶體位置 。Wine 也要避免 dynamic linker 預先把 Wine 所需的函式庫配置 (mapping) 到錯誤的位址,於是修改預設的 ELF 初始化程序,以 syscall 將相關的函式庫配置到正確的位置。

另外在 Windows® 中,每個 process 或 thread 有一塊資料結構稱做 Environment Block (PEB – Process Environment block or TEB – Thread Environment Block),這些資料中包含了 TLS slots, message queue, error code (SEH, Structured Exception Handling) 等等,這塊資料結構提供了 Windowing, Threading 以及錯誤處理等所需資訊。在建立 PEB/TEB 後,才初始化 process heap,載入執行檔,依照執行檔指示建立 stack,最後才將控制權交給執行檔的 EntryPoint

上述工作均由 NTDLL/KERNEL32 處置,NTDLL/KERNEL32 也會負責傳遞執行序資訊給 Wine Server. 至於啟動後的 Graphics Device Interface 與 X11 的圖形界面轉換由 GDI32 處理。 USER32 則實做 Windowing and Messaging subsystem. 像是一些狀態列顯示等功能,都已經實做完成。

例外一個值得一提的是錯誤處理的機制,在 Windows 上 exception handling 的方式比 Linux 中複雜許多。以 STATUS_ACCESS_VIOLATION / Segmentation fault 為例子,在 Linux 中只是吐一個 SIGSEGV 錯誤,在 Windows 中則會吐出一個 Exception,還會帶上錯誤位址 (faulting address) 等資訊,也可在 SEH 中指定 handler function 來處理錯誤事件。在 Linux 中,並沒有所謂的 system exception interface,Wine 為了模擬出 Windows 的錯誤處理機制,是將 exception 轉為 signal 來模擬。

除了上述幾個主要的核心程式外,Wine 也實做了許多軟體原件,像是 CryptographyDirectShow FrameworkDirect3D shader -> GL mapper, Network protocol stacks, DirectSound (ALSA, OSS), DirectInput, DirectShow, DirectDraw, Direct3D 等等。甚至連 MSHTML / IE 都已經以 Gecko Engine 實做。

目前 Wine 在編譯時 已經支援 64 bits 也支援 WoW64 來跑 32 bits 程式。

開發模式

Wine 是用 git 管理,任何人都可以隨意 commit patches, test cases 到 patches mailing list 上,經過公開的 code review 後就會再下一次 release 中被合併。如果有任何技術上的疑問,則會被提到開發論壇進行討論,有歧異或暫時無法解決的問題,會被彙整到問題追蹤系統中,是相當透明開放、平等的開發模式。

由於 Wine 是完全重製 Win32 APIs, 且是黑箱測試開發模式,難免會出現修東壞西的悲慘現象。為了避免舊問題在新版中重現,Wine 設計了一套測試方法,來作 Regression Testing,藉此確保軟體品質。不過這個方法只能測試功能性的問題,難免還是避免不了一些圖形界面的變異。

Wine 計劃授權原本是採用 MIT,但在市場高度期待,出現了數家不同的公司為不同的平臺提供服務,社羣為了避免多家營利公司商業競爭造成開發資源分散,2002 三月後已經改成 LGPL.

也由於授權開放,Wine 的開發成果如 D3D 也被整合到 VirtualBox 中。另外像是想重新實做開源Windows® XP/2003 的 ReactOS 計劃,其軟體層也使用 Wine Libraries。一般開發者也可以用 Winelib 作為跨平臺的函式庫,在 Linux 上將程式移植到 Win32 平臺上。 (類似 mingw)

目前在 Linux 上,Wine 對於音效支援,只有 OSS 與 ALSA。社羣已有 PulseAudio,但由於開發團隊策略上的考量,希望朝向支援 OpenAL 的方向,因此尚未被整合到官方版本。至於在 MacOS 上,其圖形界面驅動程式還是 winex11.drv ,需要使用 X Server 才能使用,OS X 上 的 Quartz 在 2010 時曾經有一部分實做,但已停止開發,功能也暫時無法使用。

使用現況

目前 Wine 計劃處在一個尷尬的狀態。Wine 已經完成很大部分的 Win32 Libraries. 但仍有尚未實做的部分,為了能夠順利使用,使用者仍必須使用 Microsoft  函式庫 (以下稱為 native)。又因為已高度實做 Wine 的函式庫 (以下稱為 build-in)往往有不相容 native 函式庫的問題。也因此使用者現階段而言並不容易只使用一套 Wine 設定來套用所有的 Win32 應用程式。

結局就是造成使用 Wine 執行 Win32 程式時,常需要搭配不同的函式庫。例如這一版本需要 native 的 yyy.dll 配合 build-in 的 zzz.dll,另外一套軟體卻可以只用 build-in dll 執行。

如果軟體出現相容性問題,不再像初期一樣,只要靠換 Win32 Libraries 就可以排除,因為每個原生函式庫有高度相依性。由於安裝軟體時,常常需要用到一些 Microsoft 的程式碼,或者偶爾也許要微調一下 Windows Registry Keys 才能順利安裝。因此常需要透過特定到程序才能成功安裝,因此網路上有許多第三方工具。最常用也最知名的就是 Winetricks.

雖然 Wine 已經開始有些像是 PicasaTeamViewer 等等的商用軟體應用,以 Wine 直接提供原生 Win32 程式給 Linux 平臺。但他們的做法,都是隨贈一套已調整完成的 Wine 系統。

由於 Wine 執行環境可以安裝在不同的 sandbox,因此系統中可以有多套不同的 Wine 同時執行。這種技巧叫做 bottle. 使用者可以透過不同的環境變數,來設定 Wine 所要使用的設定檔路徑,載入 Win32 程式時,也會啟動不同的 wine server,不同的 bottle 會是獨立的執行環境,可作不同設定或安裝不同版本的函式庫。

使用者可以透過環境變數或第三方工具,來測試配置各種不同的軟體,在 Linux 上可以使用今年剛發表的 wibom。在 MacOS 平臺上,由於編譯的困難性,可以使用 Wineskin 之類的工具來協助安裝管理 Win32 系統。此外,像是 CrossoverBordeaux 等公司也提供商業版的友善界面與預先調整好的安裝工具等服務。

Appdb 上已經有眾多程式資料,何不試試能否在 Linux 執行看看你最喜歡的 Windows 程式呢? :-)

三月 30, 2011
» CallGraphviz – call graph visualzer based on csope, graphviz and xdot

開源工具現狀

許多開發者都有介入中大型專案的經驗,常必須試圖理解原始程式的設計,或多或少都有在程式碼迷宮中找路的經驗。有些專案,程式碼結構嚴謹,軟體設計應用 Design Patterns. 見名稱、參數即可推斷程式結構,閱讀如沐春風。

但若碰到未經重構的成年老專案,程式邏輯因為年久失修,塞滿各個開發階段的臨時解決方案,常常已經複雜到難以一眼望穿理解。若是像記憶力虛弱如我,常常追了後面幾千行、跳了三個檔,就忘了前面幾個檔案的函式名稱。於是常常輔助紙本畫流程圖,但是手繪圖往往不敵跳來繞去的程式碼邏輯。還是得靠程式碼解析視覺化工具來協助理解。

繪製 Call Graph 的工具非常多,一般可以分作 Dynamic analysisStatic analysis 兩種做法。在臺灣,最知名的商業版本工具,大概是 Source Insight。不過我不用 Windows,對於缺乏原始碼的開發工具興趣也不大。

開源的 Dynamic analysis 有像是 Jserv 介紹過CodeViz 或是 ncc。不過這類工具需要 patch gcc,不特別適合嵌入式系統專案。因爲原始碼常常只支援特定平臺,或是無法取得編譯工具原始碼,此外不同版本的 compiler 偶爾會造成不同的問題,造成使用上的困難。

一種比較乾淨的做法是像 KCachegrind 利用 valgrind 來收集資料,或 Gprof2Dot 利用 gprof 的輸出資料。再者是利用 gcc 的除錯功能,把 internal representation (RTL) 倒出來,再用egyptPython-RTL 來判讀或繪圖。

至於 Static analysisFred Chien 介紹過cflow 或是 Doxygen 也有類似的繪圖功能。也有工具是配合 cscopeglobal,例如有人幫 CScope 刻過圖形界面,Vim 有個 CCTree 可用。

CallGraphviz

以上這些工具各有優缺點。

最常見的問題是許多工具無法處理 function pointer / dynamic dispatch,最終還是要人力介入。另外一個使用上的困擾是,這些程式會一口氣畫出整個程式碼的結構圖。

太多資訊其實妨礙理解,因爲用途常常只是追一個臭蟲,程式開發者只想畫出特定路徑來釐清問題。而context-sensitive 的 call graph 測試工具又耗費資源。

若用 CodeLite, Code Blocks , Eclipse CDT 等開發工具,工具已經內建或整合 cscope /global,提供 symbol lookup 功能,於是開發者很容易用滑鼠查閱函式定義或實做,或也可以搭配 LXR 來瀏覽程式碼。已經不需要像是 cbrowser 專屬的程式碼瀏覽工具

所以需要的是可以手動的將目前程式情境視覺化的工具,網路上已經有其他開發者做了 Bash: C Call Trees and Graphs 或是 Global-calltree。或是像 ypwang方法,記錄函式進出點,再手動繪圖。

這些工具大多是整合 shell scripts,操作上有點不便。另外我也不喜歡 Call Tree 的圖式,因爲樹狀圖無法表現遞迴或交互關係。

於是查找一下,決定拿 cscope 加上 GraphvizDOT 語法來用,改了一個 CallGraphviz。它的功能是一個 Graphviz 前端,後端還是使用 cscope 查 symbols,為了可以即時瀏覽就拿了 xdot 當作界面。xdot 是以 PyGtk 開發,非常容易更改,不到三百行就加入我需要的功能。
 

使用方法

  • python visualizer.py
  • 按下 “New”, 選擇要分析 C/C++ 專案目錄。
  • 於 “Search symbol” 鍵入要追蹤的函式名稱。
  • 每次鍵入新名稱,他會自動對應圖中已輸入函式是否爲 caller or callee,並自動畫圖。

CallGraphviz 可以將繪圖結果存成 dot 格式檔案,然後再利用 dot 指令轉換格式。不過它只是把曾經查過的名稱記錄起來,開啟時重新查 cscope 而已,若圖大時,每次開啟可能會十分緩慢。

原始碼可於 github 下載,授權採用 GNU Lesser General Public License.

延伸閱讀
Python Call Graph

三月 26, 2011
» CertAlert 0.0.6 for Firefox 4.0

Firefox 4.0 出來之後,一直沒有抽時間出來更新 CertAlert,不過最近看到 AT&T 上的 Facebook 流量莫名被轉到中國南韓去,似乎有某種暗黑勢力蠢蠢欲動。

頗擔心 CNNIC 有惡意作為,稍微更新了 CertAlert,讓它支援 Gecko 2.0 XPCOM API,可以裝在 Firefox 4.0 上。新版安裝檔可以於 github 下載。

Mozilla 官方 AMO 因爲疏於更新,暫時被拿下來了,將重新上傳等官方審閱後即可再次下載。

2011-03-29 01:30

官方 AMO 已經重新開放安裝,仍於申請審閱程序中。

support:

biggo.com.tw

A Django site.