作者: Hui-Hong YOU

最近在公司開始用 Docker。之前請過 Carl Su 來講 Docker 簡介，但是實際採用還是最近這幾天的事。

實際去用才會知道 Docker 箇中奧妙，不然看再多文章、再多書、聽再多夶演講，都還是會墜入五里霧中摸不著頭緒，也很容易因為用慣了典型的虛擬機，使得觀念轉不過來。

對於用過 FreeBSD 的人來說其實很好懂，因為很像當中的 jail。如果沒有用過，則我想到最簡單的譬喻，應該就是去唱卡啦OK吧：

你以為全世界都可以聽到你唱歌（你以為自己在一個完整的系統下執行），

實際上只有包廂內的朋友聽到你唱歌（但其實你是被一個 Docker 容器給隔離），

另一個房間裡的別人也聽不到你，他唱分手快樂、你唱愛我別走，兩個人不會打起來（除非經過特別設定，否則一個個容器各自獨立），

你以為你有自己專屬的全套視聽設備，但是點歌系統其實是卡啦OK業者建設的，讓你們連線共用（Host OS 資源透過 Docker Engine 調度給容器共用）。

如果這個譬喻很爛，請再隨意吐嘈我沒關係。反正最近我的自尊心與羞恥心已經低落到比馬里亞納海溝還低了。

實作時拿了 Fluentd 來打包，這一點就讓之前的我，以及諸多還不理解 Docker 的人覺得奇怪，如果照官方提供的安裝方法，其實沒有必要這樣「折騰」。何況在之前我已經用 OpsWorks (+ Chef) 寫過自動安裝的 cookbook recipe，照理講直接裝到機器上應該很快很方便，為什麼還要這樣重新發明輪子？

原因就在於 Docker 換來極大的彈性：

• 我依舊可以搭配 OpsWorks 用，事實上我為了要在 OpsWorks 上的 Ubuntu 14.04 AMI 上用，還特別寫了一則 recipe 去新增 Docker 官方的 repository 來安裝新版。
• 如果哪天我不想用 OpsWorks 了，我還是可以帶著我的 Dockerfiles, Docker images 直接叛逃、無痛轉移。
• 不同專案會有不同的 Fluentd 設定，甚至同一個 layer 底下不同的 instances 都可能會有不同的設定，在 OpsWorks 上做起來實在很阿雜，但是配合 Docker 之後，只要管好「不同的地方，載入不同的 Dockerfile，在已有的 Fluentd base image 上再用 ADD 把專屬的設定疊上去，做出一個特用 image 就好」。
• Docker 測起來很快，實務上跨 Mac (Boot2Docker) 與 Linux 開發也不覺得阿雜。用簡單一個字表達的話就是「爽」。

先到這邊，之後想到再寫…。

敲邊鼓的某位仁兄認為，過去根本沒人在意 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 曖昧未明的苦衷），卻能含括概念的譯詞。

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

實在很令人傻眼。

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

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

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

之前寫過〈開啟 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）有正常啟動，本來就能正常運用。兩者搭配起來，不誇張，就像用實機一樣。但是我也實話實說，這些要安裝的軟體套件、要設定的東西頗多、頗雜，免不了小小折騰一下。

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

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’ 更不容易出包。

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

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

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

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

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

簡單扼要的感想：

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

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