我為什麼認為「套件」比「軟體包」好

敲邊鼓的某位仁兄認為,過去根本沒人在意 package 這個譯詞問題,言下之意,是我小題大作。

不過我確實覺得這是個問題。不管這對你而言,是個大問題、小問題,或根本不是問題,對我來說,因為我跟對方同樣在意「翻譯」這件事,所以至少我覺得,這是個問題。

回顧辯論過程中,我用錯方法,一直用舉反例的方式想要闡述「某某東西不是『軟體』」而將自己逼入死胡同。

是的,我再說一次,我學藝不精,誤解「軟體」的定義,這點被屢屢打臉,我服輸。

正確的思路應該是要問:

  1. 如果有個 ‘package’ 單字放在 package management 的 context 裡,而不是 ‘software package’,面對這個 context,你在當下,只看到 literal 的資訊,是否能斬釘截鐵地確信 ‘package’ == ‘software package’  而堅信選用「軟體包」的譯詞是適當的?
  2. 你會不會犯了過度推論的邏輯問題?
  3. 前人如果考慮到 context 可能有的曖昧、模糊,用「套件」這個較為中性、泛指的譯詞,來試圖含括 package 的「概念」,是否就真如你認為的那般不合理?

辯論過程中,使得我動了火氣的地方是:

  1. 對方一開始不論青紅皂白,直覺認為我只是「不習慣」。
  2. 對方以自己的一套理論,認為「套件」這個詞不能與「包裹」的意義互通,而質疑始終堅持「套件」譯詞妥當的我有問題,認為如果我在日常生活中也把一箱箱、一包包的東西叫「套件」,那他沒話講。

即使我們在所謂「日常生活」中,也常遇到同一個名詞,有不同意義:

  1. 平面設計、印刷的「出血」;醫院急診室的「出血」
  2. 新聞台的「採訪」;圖書館辦公室的「採訪」
  3. 雜誌社的「標題」;圖書館辦公室的「標題」
  4. 使用軟體時的「物件」;買賣不動產的「物件」
  5. 小市民說的「機構」;做電腦、手機硬體設計的「機構」

今天對方可能是將「套件」解讀為「放在包裝裡的整套物品」,所以推及「包裝不等於內容物」,是把「套件」想成 kit, set 之類的。

但是就我,以及我揣測的前人所下的這個「套件」譯詞,是 ‘packed ware’ 的概念。意即我前面所述,當我不能確信 ‘package’ == ‘software package’ 時,我寧願下一個或許沒那麼直觀(因為有 context 曖昧未明的苦衷),卻能含括概念的譯詞。

兩方想法全然不一樣,所以吵起來真的不意外。

國考圖書資訊管理類科,到現在還在考 MARC 幾段在幹什麼

實在很令人傻眼。

我翻一下「103 年公務人員初等考試試題」圖書資訊管理〈中文圖書分類編目大意〉,一股怒氣就從腳底衝到腦門。

MARC 是給程式設計用的,是給機器讀的,所以才叫做機讀格式。你拿來考考生,還是考幾乎不可能碰到系統開發工作的初考考生,是有什麼鑑別度?是要鑑別誰比較會背《中國機讀編目格式》嗎?還是要真正選才?

就算在編目的實務工作中,你也不會直接操作 MARC 資料,我再說一遍,MARC 是給程式設計用的,是給機器讀的,所以才叫做機讀格式。那每年一直考一直考一直考這些 MARC 的細節,到底有什麼意義?出題老師你真的有在做編目工作嗎?如果你真的在技術服務工作中每天每天都直接操作 MARC 資料,意即寫程式去算幾位元的欄長、資料長、去把資料抓出來,那我佩服你,我跪著把你鞋子舔乾淨跟你賠罪都沒問題;倘若不是,拜託,出一些有鑑別度的題目好不好?選一些真心有志於圖書館工作的人進公家單位好不好?救救我們的圖書館事業好不好?

正確設定 Android Emulator 的硬體加速

之前寫過〈開啟 Android Emulator 的 GPU 硬體加速〉,但是偶爾還是會聽到社群朋友在抱怨 Android 本家提供的模擬器很慢,而去用其他一些第三方提供的加速模擬器,覺得很奇怪。

我對 Android 模擬器「夠快」的標準是,非高度要求「即時反應」(如遊戲、影音)、「一般」的 app 能夠跑得順,就算夠快了,而我自己設定正確的本家模擬器,是合格的。

Android 本家模擬器的硬體加速手段,其實可粗分成兩種:

  1. 使用 Intel x86 Atom System Image,那麼就可善用 CPU 的 虛擬化技術(如 Intel 的 VT)和 KVM 來使用電腦上的同質性硬體 (x86 <-> x86),大幅減少指令轉譯的成本,達成效能最佳化。
  2. 使用 Host GPU (即電腦上的顯示晶片)來加速圖形繪製,這個手法即使是使用非 Intel x86 Atom System Image 亦能受益。

所以,滿足手段 1 與 2 者能得到最好的效果;如果手段 1 很不幸地受限無法運作,至少手段 2 可以讓視覺感受上不會太過「卡頓」。

而今天我再度碰到同樣龜速的問題,發現 emulator 輸出錯誤訊息如下:

emulator: ERROR: Could not load OpenGLES emulation library: lib64OpenglRender.so: cannot open shared object file: No such file or directory
emulator: WARNING: Could not initialize OpenglES emulation, using software renderer.

原來是我將 Android SDK 的路徑改了,卻忘了更新 /etc/ld.so.conf.d/ 底下的設定檔,將 $SDK_PATH/tools/lib/ 改正後,就能回復使用手段 2。至於手段 1 如果硬體有支援、核心模組(如我使用的 kvm-intel)有正常啟動,本來就能正常運用。兩者搭配起來,不誇張,就像用實機一樣。但是我也實話實說,這些要安裝的軟體套件、要設定的東西頗多、頗雜,免不了小小折騰一下。

在 Cron 裡跑 (RVM) Ruby scripts

罕用,結果就是每次用每次忘…。

  1. 如果執行檔放在 system-wide 定義的 PATH 以外(= Cron 執行時使用的身分),就要指定絕對路徑,像是透過 RVM 安裝的 Ruby,或是在 crontab 裡載明 PATH。
  2. 如果使用 RVM 則要在 crontab 裡載明 RVM 專用的 GEM_PATH,否則就會爆 LoadError。
  3. 用 sh -c ‘target_cmds’還不夠,最好是用 sh -l -c ‘target_cmds’ 更不容易出包。

買了一把 WiNTEK ACK-230

DSC_1285

之前買了 Apple Wireless Keyboard,無奈還是不太習慣它的手感。這次換了新工作,主要的作業環境在 Mac OS X 上,我原先還是從善如流地使用 Apple Wireless Keyboard,但是幾天下來發現被「卡」到嚴重影響工作效率,心想不快點解決這問題不行。

對於這隻工作用的鍵盤,我列了幾個條件:

  1. 手感要好
  2. 不能太吵

針對條件 1,其實我可以把家裡的 Acer 6511 帶上來用,但是它的聲響還是可能影響其他人。

DSC_1287

至於市面上的黑軸鍵盤,高「貴」品牌的我買不下手,平價的 DK1087 缺貨,於是我再搜尋了「平價 好打 鍵盤」而找到 WiNTEK ACK-230。

簡單扼要的感想:

用過 Acer 6511 後,WiNTEK ACK-230 手感相比也只是落在 75~80 分而已,有點軟,但是也好過 Apple Wireless Keyboard。

不過後者真的比較安靜,在辦公室裡盡情 coding 也不怕引來側目,所以 ACK-230 還是買對了。

回家,在蘭陽觀光夜市吃晚餐

回來的路上,為了處理悠遊卡鎖卡問題,跑了一趟國光客運在宜蘭轉運站的櫃台。就順路(?)去蘭陽觀光夜市吃晚餐。一直覺得這個夜市的地點處在一個很尷尬的位置,交通動線很難讓搭乘客運的乘客經過,但是又位在居住人口較稠密的這一側,不過在地人又有多少是外食族呢?外食族當中又有誰會「吃巧而不求吃飽」的以小吃當正餐呢?

所以幾個月前跟國中好友來時,攤位還算多,此次來卻發現幾乎收了大半,冷冷清清,又門可羅雀,看了心裡實在覺得有點難過。

若要跟附近的東門夜市比較,這裡停車相對方便、有洗手間、非露天不怕雨淋,其實優點很多。

當下就想起了「あまちゃん」劇中主角回到災後的故鄉,心想是不是可以做點什麼。

吃了一碗很好吃的蚵仔麵線,再點一份蔥餅,填了一點肚子後,有點悵然地離開這裡,繼續歸途。

RTL-SDR 軟體無線電 (Software-defined radio)

偶然得知 Realtek RTL2832U 這顆 DVB-T 訊號處理晶片,搭配適當的 tuner 晶片,可以拿來做軟體無線電,也就是所謂的 RTL-SDR。看了別人寫的〈2013-09-17 廉價的Realtek RTL2832U軟體無線電〉就忍不住也去 eBay 買了一組 RTL2832U+R820T 的產品。

沒想到從香港賣家(我猜實際所在地是深圳…)發貨後到我手上,竟耗了兩個月又一週,中間我還在 eBay 提出申訴而獲得退費,實在烏龍。在收到貨後緊急聯絡賣家,補匯款給他們。真的不知道在今日,平郵過個黑水溝還會耗這麼久,好像回到了古早古早的時代。

IMG_20140501_194151

一開始我使用 RTL-SDR 附的命令列介面工具 rtl_fm 來接收訊號,實在是…不太好用,所以又去找 GUI 工具來用。

SDR# 在我的 Arch Linux 上,需安裝 PulseAudio 才能正常使用,功能也不錯,偏偏使用 Linux 的各位應該都知道,PulseAudio 製造的麻煩比解決的問題多,所以我只好再物色其他的選擇。

於是我又找了 Gqrx 來用。其實更早之前我是想先試 Gqrx 的,只是看到需要安裝的相依元件那麼多,就心生抗拒、退避三舍。後來實際動手才知道,其實沒有現成 Arch 套件、得要我手動安裝的,只有 gnuradio-osmosdr,而事實上這已經有熱心人包好的 AUR。所以在我稍微兜個小圈子,把 Gqrx (特別指定禁用 PulseAudio)編譯出來後,就有一個不錯的 GUI 可用了。

天線還是收訊的最重要因素,隨附的小天線大概只能收幾個訊號還算強的 FM 廣播。用自製的四菱形天線,則可順利收到更多電台,還很勉強地聽到一個一般民眾對話的頻道。

接收設備的參數設定則是其次,要把硬體自動增益 Hardware AGC 打開,還有依訊號品質情況設定 Filter 的寬窄幅度。

接下來我想去借或買一根木瓜天線來試試看,能否聽到更多頻道,還有收氣象圖傳真。

Ruby & Arch Linux Taiwan 陶瓷吸水杯墊設計稿釋出

Ruby & Arch Linux Taiwan 陶瓷吸水杯墊

會知道有這種陶瓷加值產品,是因為看到漫畫家漢揚貼的訊息,查了一下,並不貴。訂製後收到成品,發現印刷品質很好,業者交貨速度也很快,還可以推廣在地陶瓷,所以就接連製作了兩批 Ruby & Arch Linux Taiwan 的。Ruby 的都拿來送給社群朋友,包括在這次 RubyConf Taiwan 2014 親手送給 Matz さん。Arch Linux Taiwan 的則先採小量團購方式給社群朋友各自認購。

陶瓷吸水杯墊原稿採用 InkScape 設計,輸出為 SVG & JPEG,在此釋出,供大家自由使用。

為避免廣告嫌疑,在此恕不貼出我接洽的廠商聯絡方式,敬請見諒。

修好了 fcitx-chewing

每次輸入法壞掉,我在電腦前、網路上就近乎啞了一樣。上次修好 ibus-chewing 前,我用行列輸入法一個字一個字慢慢拆,還是不若使用注音輸入法流暢,現在臨時要我用行列,我除了基本十訣還有些模糊的印象,也早就忘光光了。

這次因為 libchewing 0.4.0 改了幾處,fcitx-chewing 果然如我預料的也壞了,我又用輕鬆輸入法搭配拼音輸入法一個字一個字慢慢拆、慢慢拼。輕鬆輸入法真的好學不易忘,我覺得最大的缺點就是它用了四排鍵來定位字根,造成選字麻煩。而這個問題我想在觸碰面板裝置上反而不是問題,如果我更進一步能在 Android 上實作一個可自動選字詞的輕鬆輸入法,我爹以及千千萬萬個不習慣注音符號、漢文素養卻不差的長輩,用起來應該會很高興。

對於不是很慣 C 的我來說,要修好輸入法不像慣 C 的夶們那麼簡單,但是秉持著「自己的輸入法自己修」精神,我還是硬著頭皮、用我程度相當彆腳的 C 與 GDB 知識去修。

上次修 ibus-chewing 時,非常幸運地用 GDB 加上人腦 debugger,在主程式一開始沒幾行就抓出型別錯誤問題,順利把 bug 解掉,後來從 iBus 跳到 Fcitx 輸入法框架,則一直開開心心地在之上使用新酷音、Anthy 分別處理中、日文輸入,沒遇過什麼問題。

而此次 fcitx-chewing 我依照編譯時的錯誤訊息,分別停用 chewing_Init(), chewing_Terminate() 以及把 chewing_zuin_String() 改用 chewing_bopomofo_String_static() 後,還是無法使用新酷音。

在這中間我翻了 libchewing 本身的文件、測試案例,不得不說 libchewing 到後來漸次補上的這些測試案例寫得很棒,是很好的新酷音實作參考範例;還翻了 fcitx/developer-handbookfcitx/fcitx-templates,幾乎把整個 fcitx-chewing 逐行審核過,收穫之一就是大概瞭解了在 Fcitx 之下如何實作一個輸入法。

我發現程式在 chewing_new() 這邊就已經未正常產生一份 context,遑論後續的操作。交叉測試之下,才發現是 userpath(使用者詞庫目錄)參數在我電腦上出了詭異的問題。libchewing 0.4.0 新增使用 SQLite 資料庫來維護使用者詞庫,而我的 userpath ($HOME/.chewing/) 底下原本該有一份 chewing.sqlite3 資料庫檔案,卻被生成為一個目錄,導致 chewing_new() -> chewing_new2() 根本無從處理,只好傳回 NULL。於是我手動移除 $HOME/.chewing/ 讓 libchewing 重建,終於讓 fcitx-chewing 可以正常運作。

我後來又翻了 libchewing 想要重現這個問題,卻怎麼也找不出問題所在,無論是 GetDefaultUserPhrasePath() 還是 InitUserphrase() 看起來都很正常,只好先擱置了。

幾個 MySQL 跳 PostgreSQL 的心得

我的 DBA 程度很遜(好吧,因為我樣樣都沾一點醬油,所以樣樣都很遜),這篇請不要期望有太多有營養的東西。

真正開始轉用 PostgreSQL 是因為它的 ltree 實在太好用,由於我的工作緣故需要能高效處理一個巨大階層樹結構(也就是物種名錄)的機制,而 MySQL 的解決方案我都覺得太迂迴、太阿雜,所以在我看到 ltree 之後,我就改投 PostgreSQL 麾下了。

我對各個 taxon 名稱予以 MD5 編碼後,再將階層存成 lable path,並建好索引。這樣處理一份有數十萬筆 taxa 的資料集,要找出任一 taxon 之下的全部子 taxon,在 PostgreSQL server 經過適當參數設定調校的環境下(見後述),瞬間就可得出結果。我當然是非常滿意。

之後我又用了 JSON 資料類型存一些 hash, array 的資料,發現我幾乎可以將 PostgreSQL 當作 MongoDB 的同質替代品來用,且沒有 32-bit 的最大容量限制,在我這裡迫於各種(我不知道的)因素未能安裝 x86-64 Linux 的伺服器,也能受惠於 JSON 式資料表述法的便利性。

一開始我用 MySQL 的觀念來用 PostgreSQL 當然是常常碰壁,譬如認證、權限系統的差異,譬如資料庫到資料表間還有層 schema。但是透過 pgAdmin 的輔助(如同 phpMyAdmin 在 MySQL 上的管理工具一哥/一姐地位),還有 PostgresSQL 明確的錯誤訊息以及詳盡的文件,適應也只是幾天內就搞定的小問題。

比較難的反而是當初要跨過自己設下的、懷疑是否真有必要「重複學習另一套資料庫軟體」的心理門檻。

至於效能,把 shared_buffers, temp_buffers, effective_cache_size 這三個預設值實在太過保守的參數調高,立即就拉上來了。這還是我在 ASUS EeeBox B202 開發機上 (Intel Atom N270, 2GB RAM) 跑出來的表現,拿到 production 的伺服器上跑就更猛了。