及時當勉勵 2004/06/07
今天看到 Tsung’s Blog 轉貼的文章，覺得內容很棒。
中文字幕的 Youtube 影片如下:
最重要的心得大概就是:
“Don’t worry about proving yourself; just improve yourself!”
“share it openly“
經驗分享者為 Dewitt Jones ，然而這句話並不是 Dewitt Jones 想出來的，而是當時的國家地理頻道的頭 Bob Gilka 說的。基於追本溯源的念頭，我花了一點時間尋找影本與專訪的出處，找到資料如下:
最早的專訪資料應該是 2011-02-22 的網誌:
影片的來源則似乎是 2017-10-19 由 Star Thrower Distribution 所上傳的影片
以上資料提供給大家參考
原名為，創新擴散理論(Diffusion of Innovation Theory)，第一次是在 Simon Sinek 在 TED 的演講中聽到這個理論的。
註: 約於影片中的 00:11:00 秒附近。
這項理論揭示了幾個要點:
要點1: 市場上可能存在的比例分佈
2.5% 是發明家
13.5% 是早期使用者
34% 是早期的大多數
34% 是晚期的大多數
16% 是落後者
要點2: 大眾市場接受新觀念的關鍵點
15% ~ 18% 是大眾市場普及接受的關鍵比例
維基百科: https://en.wikipedia.org/wiki/Diffusion_of_innovations
理論來源: Everett Rogers 於 1962 年發表的 Diffusion of Innovations 一書中提出
在數不盡的論戰之中，尤其是政策的討論，總不時會出現 “人都是安份守法的，於是…”、”人都是投機自私剝削他人的，於是…”、等等等的說法，並不時舉出真實案例與故事來加強自己的論述。而同一時間，另一方，也往往總是能提出對應的反例來駁斥(打臉)這一方，眾人無不拍手叫好。這樣的場景，已經不知道反複重演了多少次，仍不斷的重複中。
我把這類相似的場景化約為，”人性本善 v.s. 人性本惡” 的二元論戰問題。
依邏輯來看，上述用一個反例來反駁對方論述，是數學上常用的反證法。訴諸事實與邏輯是好事，然而，這有個詭異的地方。就是，兩方都各自提出證明己方是 True 的一些事實案例，也各自提出一些事實案例證明對方是 False。那麼，就雙方提出的事實們的總合來說，要嘛是雙方都 True，要嘛雙方都 False。但這顯然不合理，因為雙方的論點是互斥對立的。也就是說，這是個”零和賽局”。所以，這樣的爭論，必無可避免的陷入，雙方各堅持己見，並完全否定與忽略對方的事實與論點，而且永無止盡的交互攻擊了。
那麼，有沒有辦法跳脫這個無止盡的泥沼呢?
有的，我認為關鍵在於轉向統計事實的全局觀討論。
現代社會的規模動輒上百萬人，不必然全部都善良或全部都邪惡。現實生活中，必然有少數特别善良，也必然有少數特別邪惡，還有許許多多介於中間好壞程度不一的人，和許多隨環境氛氛而跟著好、跟著壞的人。於是，在搜集並衡量所有人的整體狀況，預期會得到一項統計分佈示意圖如下:
註: 僅概念示意圖。
在往上拉到全局的統計概觀之後，再回頭檢視 “本善”、”本惡” 的論點，就一切就清楚了。不難理解，其實 “本善”、”本惡” 可說都對，也都不對。都對的原因是，社會上的確存在有一定比例的少數特別的善良(本善)，也存在一定比例的少數特別的邪惡(本惡)。而都不對的原因是，他們都只用局部的片面案例，來概括整體的狀況(以偏概全)。因此，只要將原本一刀切的二元分法，升級到統計分佈的分眾管理的思考，就能得到完整而清楚的出路了。
上述的觀念不難理解。然而，”當局者迷、旁觀者清”，要將觀念落實在生活中，或是要從身陷於論戰之中的情緒跳脫出來，並不是那麼容易。
目前我想到的修正方式是：
其一，嘗試在問句之中，習慣性的加上”統計”二字。
例如: 將 “這論點根據的事實為何?” 改為 “這論點根據的統計事實為何?” 。有些習慣是由外而內的，一旦對話或思考中多了”統計”這二字，有助於提醒自己意識到”局部/全局”的差異，而盡快從偏見中脫身。
其二，嘗試取得統計事實
當兩方的統計事實有出入，或是根本沒有統計事實時，那麼當下最重要的事是，就是去取得統計事實。唯有不斷取得並揭露統計事實，才能跳脫零和論戰而導向收斂的事實真相。
小時候自然科學提到的順序大致如下：
事實(現象、實驗結果、…) => 假說 => 理論 => 定律
而這樣的順序不知不覺中，也影響了我們對這些階段的高低安排直覺，示意圖如下:
但仔細一想，這其實不太合理。事實就是事實，”事實”應該是最高位階才是啊!!
反思修正一下，比較合理的安排如下:
也就是說。”事實”處於最高位階，在任何”假說”、”理論”、”定律”之上。
為何要特別寫一篇文章來說明這件事呢? 因為，我發現這看似微小的差異，其實不知不覺中，影響了我們在接受訊息時的態度傾向。我以下面兩張示意圖來表示:
當新的”事實”出現時，若是和定律、理論、假說之一抵觸的情況下，若依原先的位階排序，直覺下容易傾向先去否定跟忽略位階較低的新”事實”，而堅持心中位階較高的想法理論。然而，若將”事實”的位階修正為最高的話，那麼，當遇到新出現的”事實”時，較容易放下對既定想法的堅持，而試著去調整與建立出新的理論，來同時適應新知的和已知的事實。
或許偶爾提醒自己在直覺上的盲點，有助於自己能更坦然的面對新的事物，與對待別人的發現與看法。
補充:
publish on 2018/01/08
補充:
參考 “拼圖思考法” 一文。以拼圖思考法的角度來看，散落各個角落的”事實”，正是拼圖思考中的拼圖碎片。
補充:
補充:
“快思慢想”一書中，有提到”認知不協調”的現象。
約是在 2014 年前後，我想通了一件事，但一直遲未將想法化為文字。今天終於静下心來作這件事了，我想要說明的是，為何在某些效能瓶頸的關頭，我會主張作深度分析優化，而非立即性擴充資源緩解眼前的問題。
舉電商網站經營為例，資料量主要有會員、訂單、商品等資料，大致可初估資料的複雜度以 n^3 的速度在膨脹，因此所需的運算需求量也以這速度跟著成長。這可用下方這示意圖來表示：
其中X軸為資料量，Y軸為硬體運算量，而運算資源需求則是原點連往A、B、C三點的這條曲線。
當網站逐漸成長，終於來到第一個效能瓶頸點(A) 時，網站又慢又卡、硬體滿載，並已危及正常運作的時候。我們有2個方向的選擇:
《方案一》直接擴充硬體。這可能馬上就解決了(假設是 1 天)，相對而言較快速而簡單。
《方案二》分析軟體程式，找出並修正潛在的程式瓶頸。這工程相對耗時長，可能要耗上不少時間(假設是 5-14天)，也會有相應的開發成本支出。
因為網站瓶頸會影響營業收入，所以在規避損失的心態下[1]，多數人會選擇 《方案一》的路線，直接將資源從 L1 提升到 L2 ，以盡快脫離眼前損失的狀態。接下來發展的狀況大致如下:
1. 很快就擱置了改善軟體效率的念頭
A. 因為眼前壓力解除了
B. 有其他更重要的事 ( 應付眼前業務、新功能開發、...)·
C. 非受迫性的額外支出 ( 需要另外撥出預算跟時間 )
2. 資料量隨時間持續成長，然後又遇到新的瓶頸點
3. 在瓶頸點再度面臨兩個選擇，但基於
A. 業務量較先前更大，相同時間的代價損失並上一次更高
B. 營運壓力更大，工作人員比先前更加心有餘而力不足
C. 先規避眼前立即的損失再說
4. 再度選擇《方案一》，然後重複回到 1.
最後反覆重覆上述流程，直到獲利跟時間餘裕都被最後吃光，再無法越過某個天花板為止。
那麼，若是一開始在 A 點時，選擇《方案二》的路線會是如何?
從圖中簡單的估計一下 A-P-Q-R 的路線，(假設資料量以每個月 1W 的速度成長)，雖然一開始多花了 15 天的時間，但遇到資源關卡 L2 的時間(瓶頸點R) 可能約是 5.5 個月之後。相較之下， A-B-C 的路線，一開始只花 1 天，但可能約 2.5 個月就抵達資源關卡 L2 (瓶頸點B)，然後不到 2.5 個月，就抵達資源關卡 L3 (瓶頸點C)。
於是，同樣過了 6 個月的時間，面對相同的資料量，兩者不管是在資源耗用度，或是在時間餘裕度上，都形成了此消彼長的差距。而這差異，其實早在第一個瓶頸點 (A) 當下的選擇就決定了。
最早我以為，有很大的可能，會在 A-B-C 的過程中，轉變另一個選擇。但是，當我不只一次遇到，已經發展到 C 狀態的苦主們，在討論解法時仍不死心的一再追問說”有沒有更快的方法”的時候，我就深深明白到，人的選擇是有慣性的。一旦選擇《方案一》的路線，除非個性或環境條件有變化，否則就只會一直選擇《方案一》下去，直到被迫不得不改變為止。
同樣的，選擇 《方案二》 的路線，一旦獲得了成功經驗後，也會持續的選擇 《方案二》 的路線下去。唯一不同的是，《方案二》 的路線中，任何一點要切換選擇 《方案一》 相對較容易，所以 《方案二》 比較是一開始選擇較辛苦，但後面的選擇空間是越來越寬裕的路線。
因此，這就是為何在效能瓶頸的問題上，我會主張優先作分析優化，而非立即擴充資源跳過眼前損失的原因。
思考1
“先緩解眼前的問題再說” 有錯嗎?
這没有錯，這是人務實生存的天性，即便我也是如此，而且如果病人已經快要死了，還去關心這個人的儀容整不整齊，也很不合理。所以，危機處理是必要的，我並不否定這件事。
真正的問題點在於，絕大多數的人在眼前的問題緩解後，就將問題給遺忘了。
如果你是個問題緩解後，仍會自發性的長期追蹤跟解決該問題的人，你一點都不需要在意這個問題[2]。但如果你是個問題緩解後，就很快的健忘，然後一再重覆遇到類似問題的人，那麼先忍住待在 “面對眼前問題的損失” 的這個痛苦之中，可能是唯一個能不斷刺激推動你徹底解決問題的唯一動力。
說到這裡，可能有不少人會抗議說:
“痛的是我，又不是你，講的好像很簡單一樣”
是的，完全没錯，這是個困難而且違反直覺的選擇。也正因為真正痛的人不是自己，而是落在作決定跟承擔決定的人身上，所以更需要溝通與說明觀念上的落差。這也是我花這麼多時間寫下這一篇文章的動機之一。
希望讓更多人能正視到，這些簡單決定背後隱藏的長期代價，並理解另一類型的想法為何。而最後不論你認不認同這個想法，最終的判斷跟決定權都還是完全掌握在您的手上(也應該完全承擔)，這始終絲毫未變。
如果文中的觀點能帶給你一個新的角度，或是協助你解釋跟說明給另一個人聽，就太好了。
但若是因此在對方未認同下，擅自幫別人作決定而執行的話，我想就不是那麼好了。
也許你是在為別人好，但另一個角度來看，或許也是在迴避”解釋說明跟尋求共識”這條較困難但較長遠的道路。
思考2
另一個近期想通的是，這個想法角度，不只侷限在軟體程式與硬體資源的選擇問題上。
相同的問題也出現在程式開發上的程式架構選擇，開發流程，開發工具，工作方法上…
舉例來說，當我們在努力開發程式時，我們可能會為了跳過程式封裝的限制，而直接複製程式碼片段到我們要用的地方，或是作一些違反常軌的 workaround 。而隨著程式碼片段的複本越來越多，且更新狀態不一致，最後不斷增長的複雜度跟層出不窮的 bug 與斷點，就耗光了程式設計師的腦力跟時間。於是類似的命題或許就會像是:
“要快速拆裝 workaround 完成新功能再說，還是要花更多時間遵循架構，甚至重構改良某些元件?”
其他問題像是:
“要直接加班先出貨眼前的積存訂單，還是要花時間研究找出工作流程中的效率問題，以簡省未來的工作時間?”
“先把眼前這題型背起來再說，還是要花多一點時間了解題目背後原理，以應變未來不同的題目變化?”
…
在這許不同的事件上，都有類似的瓶頸問題性質。
思考3
這個思維不適用於生活中的所有面向，因為人生有限，每個問題都要這樣分析面對太累了，不可能。
以上，
希望以上幾點分享對大家有幫助。
[1]. 規避損失的傾向參考”展望理論”
[2]. 有趣的是，一個長期追蹤跟解決問題的人，還會遇到上述種種的問題嗎?
記得很久之前，(註:2014-09-02)，有個問題一直很困擾我。就是我的筆電，只要開機一段時間，就會在某個時間點就會突然產生 CPU 飆高，風扇一直狂轉的狀況。即使把所有應用程式關閉，仍沒辦法穩定下來，直到我重啟 Xorg 視窗系統，才會恢復正常。這個問題，常常無預警的中斷我的電腦操作，搞得我很痛苦。
我試圖找出問題的根源在那裡，大致將可能的嫌疑犯縮小到 Xorg,Firefox,Chrome,qtile(Window Manager) 這4個主程式。不過，一直沒辦法精確的 reproduce 問題的發生。當時，正值 firefox 跟 chrome 在競爭效能之際，我看 top 的資料，都是 firefox 用的資源比 chrome 還多，所以有好一段時間，以為罪魁禍首是 firefox 。
後來，我開始接觸並上手 ganglia/graphite 這類監測工具，有天我想到，之前都是在監看遠端主機的數據，我何不運用這工具直接觀測我自己每天在用的NB呢?! 於是我開始撰寫幾個抓 cputime/memory 的script 跟設定，我直到我後來取得下面這張關鍵數據圖之後，我才明白，原來我的筆電上的問題源頭是 chrome。
從上圖中可以觀察到，Xorg 跟 chrome 的 cputime 在執行到某一個時間點時，就同時出現斜率的變化，跟問題症狀出現的時間也吻合，我這才恍然大悟, 原來禍首是 chrome。而這關鍵證據，也洗清了 firefox 的嫌疑。最後是分析出，是 chrome 有用到 graphic render 加速的功能，關閉後就沒事了。
後來又有一次，大約是 2015/02/20 前後，有更新系統，升級了好些函式庫， firefox 也從 34版升級到 36版，之後就又產生類似的 Xorg reset 的問題。幸運的是，當時我已經建好有觀測數據的機制，再加上有高手在網路上的討論幫忙，最後將分析範圍縮小至 Xorg intel driver 跟 firefox 的 render 加速相關的功能。
其中，由上圖這張當時取得的數據圖中，可以看到 Xorg 的 vesa/intel 驅動程式的不同，及 accel 的 on/off 的一些變化。由此可證實是 Xorg accel 跟其相關的下游應用程式的部份所致。雖然，最終沒能找出是那一段程式導致 mem leak ，但透過更換 driver 並關閉 accel 的選項，暫時避免掉嚴重的 reset 危機。
(註: 後來 firefox 在某一版本更新後，該問題就消失了)
這兩次經驗(還有先前的一些小案例)，給我非常非常大的啟發。
以往程式 debug 經驗，多數都依賴 gdb, xdebug, … 或是跑 unit test 來測試程式的問題，這些通常重複操作就能重現一樣的問題。但對於這類正常執行運作一段時間，然後突然崩潰的問題，常常是束手無策。因為，問題發生的那瞬間，我們往往不在現場，也沒有任何除錯紀錄。沒想到，僅僅透過簡單的 cputime/memory 這2道的數據偵測歷史紀錄，對問題的原因分析的幫助會這麼大。
這也讓我意識到，將飛行安全提升到更高等級的關鍵，或許不是風洞測試，而是黑盒子(Flight Recorder)。想想看，一台穩定飛行20年的飛機，出事的時候就只有那瞬間，我們只有一次機會可以補捉相關線索。我想，在時光機發明出來之前，只有透過 Logger 機制，才能迎戰這類 runtime 執行期的問題。這也讓我開始有了 Logger Design Driven 這個想法思考。
最後，再提供一張當時截圖到的 Xorg 在系統升級前後的對照:
從上圖中，可以觀察到 Xorg 在系統更新前的舊版本，其使用的 mem 都不到 200MB , 而且運作 2~3 個星期以上，都沒有任何 mem 用量累積。 zero memory leak 水準的軟體確實存在，是真的可以達成的，而且就在我每天都在使用的軟體之中。或許，更高水準的軟體方法，不見得在最新的技術潮流，而是隱身在這些老牌軟體專案的某個角落，等待著我們再重新去發掘它。
註1:
FB 上的留言討論
https://www.facebook.com/groups/hackingday/permalink/903494983005834/
註2:
我所使用的觀測工具是 shell script + collectd + graphite/influxdb
我寫的 scripts 大致如下:
每隔一陣子，關於高雄捷運是不是虧錢的話題，就要反覆再來個一次。
我感到十分厭煩，然而關於自己家鄉的議題，面對紛擾總無法視而不見。
網路上各方有各方的說法，很難分得清楚誰是真知灼見，誰是詭辯。
而且目前網路上查到的資料，多是斷章取義，或是先射箭再畫靶的報導或評論。
想要獲得真相，我想最好的方式就是，自行去取得第一手的資料作評估。
於是，這兩天花了一點時間，以程式抓取數據並後置分析了一下，結果如下:
數據分析結果
高雄捷運 2008/03 ~ 2017/03 的運量趨勢圖
( 單日平均運量，以7日為計算週期 )
台北捷運+高雄捷運 1996/03 ~ 2017/03 的運量趨勢圖
( 單日平均運量，以7日為計算週期 )
以下是我根據上述資料，個人的解讀與看法，如下:
Q1: 高雄捷運搭的人多不多?
目前的每日運量大約是 17 萬人次。
若高雄市人口數以 278 萬來估算的話，每天大約有 6% 人坐捷運。
台北捷運每日運量接近 200 萬人次。
若雙北以 667 萬人口計的話，每日運量約 30% 坐捷運。
Q2: 高捷的運量是否有持續成長?
在 2013 年之後，運量似乎就沒有再顯著的成長了。
Q3: 為什麼高雄捷運的運量上不去?
這個問題，我沒有答案，但我發現到幾個線索:
首先，台北捷運也不是一開始就有百萬運量的。
台北捷運前2年的運量，跟高雄捷運也是差不多的狀況，甚至更少。
但是，在 1998 年底，跟 1999 年底，都各有一次跳躍式的成長。
於是我查詢對照了一下，維基百科上台北捷運的歷史資料。
發現這兩個時間點，分別是:
尤其是1999年底，通車的路線共同構成狀似「卄」字的路網，運量出現非常顯著的成長。
也就是說，捷運系統成長的關鍵，跟打通捷運路網的連貫性，是非常直接相關的。
在世界各國這麼多已成熟系統的先例經驗下，我想捷運系統的成長曲線跟模式，及失敗原因，應該有很多相關的交通運輸科學的研究跟經驗，可作為參考依據。
如果，高雄捷運無法成長的原因，是因為路網還不夠密集的話，或許解決方向，應該是及早投入資源補全路網，嘗試將平均使用比率，從 6% 往上提升至 20% 以上，進入良性維持階段。而不是讓這種不上不下的狀況持續拖下去。
Q4: 會不會高雄本身是不適合作捷運的?
這也是很有可能的，畢竟北高兩地的背景環境是不同的。
樂觀來說，高雄捷運目前路網確實還不夠密集，使用率才 6% ，可能還有不少提升的空間。
但我們也無法確知未來發展的上限會是多少，會不會最後變成是長期虧損的大錢坑?
最好的方式，應該是透過運輸科學來作”有根據可稽核”的試算跟評估。
而不是僅依據少數人主觀直覺的贊成或反對。
假設一個建設的規劃金額達到 1000 億，若我們額外投入 1 億(即0.1%) 的預先研究評估，而能提前發現盲點，避開錯誤的決策而省下 999億(即99.9%) 的資源時，其實是非常值得的。
反思(一)
我想補提兩個看法作為參考:
其一，台北捷運開通的前兩年，其實反對跟批評的聲音並不小，而當初木柵線的爭議也讓捷運的發展飽受壓力。如果，我們再次回到 19 年前的 1998 年，我們要如何看待當時的捷運發展? 嘲諷它嗎? 還是投入資源支持它的發展?
其二，熊本市，高雄市的姊妹市，人口約 76 萬人，僅高雄的 1/4 強，成本攤提的壓力更高，依然營運有健全的交通軌道網絡。如果人口 1/4 的熊本市能作得到，為什麼高雄作不到?
或許這兩個經驗跟歷史發展的是可以作參考的。
反思(二)
我自己回高雄搭捷運時，也常遇到車廂擠滿人的情況，然而整體的數據事實跟個人的主觀感受仍是有落差的。
這給我一個很大的啟示是，”親身經歷”有其侷限性，即便是每個人都忠實的根據親身經驗來作理性辯證，仍不一定能得到完整真相跟事實。
這也說明，有些事實真相，單靠人跟人之間的溝通、辯證是作不到的。
即便是政治上達成共識，而取得的結論，也並不是真正的事實與真相。
要取得完整的真相與事實，只能透過全局的科學數據與統計。
若只侷限在局部主觀經歷的辯證，最終只能讓我們陷於意識型態對抗的泥淖，不斷重覆循環空耗而已。
反思(三)
目前台灣的人口數是在負成長的，未來也長期呈現人口老化的趨勢。
而台灣未來的軌道運輸規劃跟財務攤提，是否有考慮進這人口發展趨勢?
當台灣年金問題，因人口趨勢跟經濟局勢變化，而有大幅的落差之際。
我們是否也該將此因素，也列入運輸發展評估的重要因子之一?
眼前已經在發生的慘痛錯誤，我們要眼睜睜再看著它重複一次嗎?
反思(四)
交通網絡的不必然只是軌道系統而已。
近年來， c-bike 跟 ubike 補全了捷運路網的不足，其成效跟影響是非常卓越的。
而新提出的”電動汽車共享”的概念(或電動機車共享)，或許也非常有機會，可以在不用巨額的軌道建設下，提升公眾運輸的涵蓋率。
目前台北高雄兩地，都有嘗試在引進這樣的建議，我覺得是非常值得肯定跟期待的。
反思(五)
在未來，我認為有巨大潛力的運輸系統是，自駕車。
當自駕車持續發展，而成熟到可以上路實用時，自駕車非常有可能會發展出如計程車般乘車服務體系。
而這趨勢，是很有可能在 20 年之後實現的。
若此趨勢真的實現時，軌道運輸的需求跟必要性，還有計程車產業，都將受到巨大的衝擊。
若我們忽視這個可能性的話，很有可能在 20 年後，軌道都剛建好了，正要進入攤提回本階段時，正好遇到自駕車全面興起的時代。
屆時迎面而來的，可能不再是美好的交通願景，而是一筆又一筆沈重的長期債單。
以上。
備註更新:
2017-05-12
我將抓取資料的 scripts 跟資料來源出處，都上傳發佈到 github 上，歡迎有興趣的人自行參考取用
https://github.com/matlinuxer2/metro_stat
想在 docker 建一個 gentoo 的 LAMP 測試環境，但安裝完 apache, mysql, php-fpm, … 後，卻卡關了。
原因在於 gentoo 預設的 init 系統是 openrc，而 openrc 不支援 docker 環境。
所以，無法以
service apache2 start
或
/etc/init.d/apache2 start
這樣的方式來啟動 LAMP 相關 daemon 。
但是，為什麼 Debian 的 docker image 就可以呢?
於是我比對了一下 Debian 的狀況，發現 Debian 的 /usr/sbin/service ，還有 /etc/init.d/ 下的 init script 實作中有考慮到 virtual machine 的環境，因此可以在 docker 下執行。
而 gentoo 的 /etc/init.d/ 下的 init script 則是都綁定 openrc ，但 openrc 不支援在 docker 裡使用。而如果在 gentoo 裡不使用 openrc 的話，就相當於要自己弄所有 daemon ( apache/mysql/php/sshd/… ) 的 init script。這代價太大了，而且即使今天硬幹成功了，未來也不易維護跟重複使用。
後來，想到的另一條路是，將 openrc 換掉，改成 systemd 試試看。現在大部份的 daemon 套件都有附 for systemd 的 init script。所以，就改往 systemd 的方向來 survey。
改用 systemd 的好處是，可以接軌各大 Linux distro 的主流趨勢。( 註: 根據 https://zh.wikipedia.org/wiki/Init 的描述，至2015年，大部分Linux發行版都已採用新的systemd )
不過，另一方面的顧慮是，systemd 目前不符合 Gentoo Linux / Funtoo Linux 的預設設定。而且， Gentoo Linux / Funtoo Linux 的創始人，也公開宣示過不支援 systemd。( 註: http://www.funtoo.org/Funtoo_Linux_FAQ 的 “Do you support systemd?” 一節 )
這個狀況至今仍是僵持在那邊。
撇開上述的討論，繼續原本的安裝 system 的步驟。一開始想說，只要安裝 systemd 之後，再切換成啟動 systemd 即可，然而，事情沒這麼簡單。因為 systemd 的啟動過程中，會用到 /sys/fs/cgroup/systemd 目錄，但作為 host OS 的 Gentoo Linux 並沒有這個目錄 ( 因為 Gentoo Linux 預設不使用 systemd ，自然也沒有 /sys/fs/cgroup/systemd )
所以，必須要自行手動作 workaround 如下:
mkdir -p /sys/fs/cgroup/systemd mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd mkdir -p /sys/fs/cgroup/systemd/user echo $$ > /sys/fs/cgroup/systemd/user/cgroup.procs
另外，啟動 gentoo with systemd 的指令也要加上選項參數如下:
opts="" opts="$opts -d " opts="$opts -v /sys/fs/cgroup:/sys/fs/cgroup:ro " opts="$opts --privileged " opts="$opts --cap-add SYS_ADMIN " docker run $opts <image id> /usr/lib/systemd/systemd
這樣子就可以啟動一個有 systemd 的 Gentoo Linux instance 了。
為了方便日後 Recycle 使用，我另外設置了 autobuild 的 docker repository 放在 docker hub 跟 github 上
https://hub.docker.com/r/matlinuxer2/docker-gentoo-systemd/
https://github.com/matlinuxer2/docker-gentoo-systemd
歡迎有興趣的人自行取用。
這是個對沉默的人不利生存的年代，當大多數的人的注意力都被FB動態和碎片化新聞洗走後，低調的人似乎只能自行默默的死去。為了生存，只能強迫自己也加入刷存在感的行列，試著提升一點個人的存在價值。
其實我一直有保持有思考跟紀錄心得的習慣，只是很少主動在FB/網路上發表自己的看法。我知道，寫Blog跟發表網路評論對於個人價值提升有很多好處, 很多實際案例擺在眼前，而我自己也熟悉這些網路平台跟工具。然而，但為何自己總是佇足不前呢?
除了對寫文章的惰性外，另一個或許就是對自我變質的害怕吧…。一旦漸漸有了影響力跟身價，成為了某個”咖”之後，會不會就也開始端起架子，變成一個連當初的自己也不認同的人呢？就好像當一個員工，當上主管後，就也漸漸變成自己當初最討厭的老闆一樣？
我不知道。但面對未知的未來，也只能試著走下去看看了。
除了上述負面的想法之外，其實也有其他正面的動機，驅使我繼續作這件事。
其一，近期在整理過去資料的時候，意外發現我過去無意間寫下的心得，也曾在網路上的某處，鼓勵了某些人。雖然，自己並不如對方所想像得那麼偉大，而别人的成功也絕大部份是他自己認真努力的成果。然而，對於”自己的文章對別人有點幫助”的這件事，還是感到很開心。
其二，對生活中遇到的時事見聞，常常會激發心中的想法。許多想法其實是重複的出現並繚繞心中, 又長期找不到知音傾訴，久了就成為心中的包袱。我發現，將這些想法好好的沉澱，寫下來成文章之後，心中的包袱就好像在那瞬間放下了，干擾跟分心的因子也從此少了一個。
其三, 我現場解說的技巧不流利. 對於我想說的內容,若能用網頁文章轉貼給討論對象的話，我就不需要趕在有限的時間內, 喋喋不休的硬塞給別人了. 想聽的人,隨時都可以打開來慢慢的看, 我也不用再一直掛心自己臨場表現好不好, 擔心講不完或忘掉漏掉什麼的, 只消讓一篇寫好的文章在網路上的某處，靜靜地傳達給對方即可。
其四，寫文章很花時間，但更長遠來看，若文章的內容能被重複使用的話，今天花了1.5小時寫文章, 未來可能因此省去3~5次20分鐘的口頭解釋, 其實是不斷地省下更多的時間和耐心. 如果, 我寫的內容能回答某些常見疑惑或月經題的話, 或許我不只能幫自己省時間，還能幫别人省時間.
其五，整理舊文時，偶爾意外發現一些早已忘記的生活點滴。坦言，讓別人看到自己真實生活的不同面貌,還真會有點不自在，但回顧曾留下的紀錄時，往往都還是慶幸當初有紀錄下來的。這些紀錄，讓我在這個被快速遺忘的時代中，好像還擁有點什麼一樣。
以上，大致寫下了這次復筆的幾點想法，希望未來的自己感到迷惑時，能再回頭看看一下當時的心境。
加油!
出社會前，我的人生經過了幾次重要的考試:
* 高中聯考(1997)
* 大學聯考(2000)
* 研究所入學考試(2004)
* 研究所入學考試(2005)
其中 2005 年的研究所考試對我意義重大，因為這次考試的過程中，我體悟出和以往不同的作事方式。
研究所的入學考試大約是在 2005/04 月左右，我大約於 2004/09 月開始準備。因為我非本科生，所以前期都在補念相關科目的書籍，並於寒假(約 2005/02 月)開始密集練習考試習題跟歷屆考古題。我先是搜集了各校前五年各科的考題，然後逐一對自己進行模擬考。
過程是挫折連連，尤其是對非本科生的人來說，要熟悉 bits/bytes 的運作跟邏輯相對吃力，每次練習完對照答案，都是一次又一次挫折跟自我懷疑的感覺。然而，在所有挫折中，最令我掛在心上的，是一次試考中出現了曾經出現過的考題，前一次作不出來答錯了，事後也看過答案了，解法也念過了，然而，當這個題目又一模一樣的再次出現在眼前時，我居然還是作不出來！
“天哪，連這個明顯送分的題目，我居然也拿不到”
如果這樣一個，書也唸過，也試考練習過，連答案解法也都看過的題目，我都無法得分的話，不就代表我在真正的考試裡有準備跟沒準備其實是沒什麼差別的。當下的我心中充滿懊惱、憤怒、自我懷疑、羞愧，想到距考試日期僅剩2個月的時間，還有那麼多東西沒唸完，卻沒什麼實質提升。我草草寫完考題，充滿心虛的只想快點了結這回合，而校對答案的難堪分數，讓心情跌下更深谷底。
我離開了地下室，在圖書館附近繞繞放空了一下。後來靜下心想想，比起難看的分數，我更加在意自己重複失敗在完全相同的考題。
所以我下了一個決定，書沒念完就算了，考古題沒作完就算了，但我要我曾失敗過的題目絕不再錯第二次。
我先是暫停作新的考題，回頭把我之前曾作錯過的習題跟考題都搜集起來，分類並找出相似的題型，然後再重新練習。抄答案寫一次，矇答案寫一次，空白紙寫一次，並加強驗算，不斷重複練習，直到我有100%把握知道遇相同考題時，用背的也背的出來為止，然後再繼續練習下一個失敗過的題目。
是的，重複練習這些失敗的考題確實比一般人耗了跟3~5倍時間，當我像烏龜一樣還在舊題目上慢慢爬的時候，圖書館的地下讀書室的其他人，書一頁又一頁的往前翻，練習考題的人一個個振筆疾書，我確實感到害怕又焦慮。然而，就在我修正一個又一個的失敗考題後，心中的不踏實感卻慢慢消失了。在這過程中，我體會到幾個心得:
1. 本來就已經會作並作對的題目，其實不太需要再花時間練習。會了就是會了，練習已經會的題目，只是增加信心跟熟練度，對最終結果是沒什麼差別的。其實我們真正該注焦的，是失敗的題目。
2. 失敗的題目一開始搜集起來很多，但整理分析後發現，許多題目其實是類似的。將相似題目整理成同一題型後，就發現這些題目都指向自己同一個盲點。針對自己的那個盲點修正後，便成功解決了其中一題，也解決了同類題型的所有題目。相對的，若盲點沒有修正的話，也表示有很多同類型的地方會失分。
3. 因為我針對失敗的題目作密集練習，練習到我有充足的把握絕不再錯第二次。所以這些會失敗的題目，就像被我的”答題濾網”給過濾掉了一樣。而隨著練習過的失敗題目越多，我的答題濾網只會越密集，越密集則勝率只會增加不會減少。就好像一個足球門將，如果針對每一個防守失敗球不斷練習，讓同一種漏洞死角不再出現，防守率就只會上升而不會下降。
簡單來說，就是用盡一切努力，修正自己的盲點並確保不會重複相同的錯誤。一旦能作到這一點，剩下的就是放寬心的不斷去實戰、擁抱新的失敗經驗、跟發掘自己新的盲點。對自己懷抱信心，因為不犯相同的錯誤就只進不退，勝率遲早會站在我們這一邊。
很幸運的，我在研究所入學考試取得不錯的表現，並取得入學資格。
雖然事隔多年，很多考試的東西早就都忘光了，但這個體悟仍深深的影響我到現在，在此紀錄下我的心得。
相關參考:
2017-05-09
讀到這篇文章，文中提到針對弱點的練習，有相互印證
2018-01-26