Don’t Prove…Improve!

今天看到 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 的網誌:

Don’t Prove…Improve!

影片的來源則似乎是 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。但這顯然不合理,因為雙方的論點是互斥對立的。也就是說,這是個”零和賽局”。所以,這樣的爭論,必無可避免的陷入,雙方各堅持己見,並完全否定與忽略對方的事實與論點,而且永無止盡的交互攻擊了。

View post on imgur.com

那麼,有沒有辦法跳脫這個無止盡的泥沼呢?

有的,我認為關鍵在於轉向統計事實的全局觀討論。

現代社會的規模動輒上百萬人,不必然全部都善良或全部都邪惡。現實生活中,必然有少數特别善良,也必然有少數特別邪惡,還有許許多多介於中間好壞程度不一的人,和許多隨環境氛氛而跟著好、跟著壞的人。於是,在搜集並衡量所有人的整體狀況,預期會得到一項統計分佈示意圖如下:

View post on imgur.com

註: 僅概念示意圖。

在往上拉到全局的統計概觀之後,再回頭檢視 “本善”、”本惡” 的論點,就一切就清楚了。不難理解,其實 “本善”、”本惡” 可說都對,也都不對。都對的原因是,社會上的確存在有一定比例的少數特別的善良(本善),也存在一定比例的少數特別的邪惡(本惡)。而都不對的原因是,他們都只用局部的片面案例,來概括整體的狀況(以偏概全)。因此,只要將原本一刀切的二元分法,升級到統計分佈的分眾管理的思考,就能得到完整而清楚的出路了。

上述的觀念不難理解。然而,”當局者迷、旁觀者清”,要將觀念落實在生活中,或是要從身陷於論戰之中的情緒跳脫出來,並不是那麼容易。

目前我想到的修正方式是:

其一,嘗試在問句之中,習慣性的加上”統計”二字。

例如: 將 “這論點根據的事實為何?” 改為 “這論點根據的統計事實為何?” 。有些習慣是由外而內的,一旦對話或思考中多了”統計”這二字,有助於提醒自己意識到”局部/全局”的差異,而盡快從偏見中脫身。

其二,嘗試取得統計事實

當兩方的統計事實有出入,或是根本沒有統計事實時,那麼當下最重要的事是,就是去取得統計事實。唯有不斷取得並揭露統計事實,才能跳脫零和論戰而導向收斂的事實真相。

事實、假說、理論、定律

小時候自然科學提到的順序大致如下:

事實(現象、實驗結果、…) => 假說 => 理論 => 定律

而這樣的順序不知不覺中,也影響了我們對這些階段的高低安排直覺,示意圖如下:

View post on imgur.com

但仔細一想,這其實不太合理。事實就是事實,”事實”應該是最高位階才是啊!!

反思修正一下,比較合理的安排如下:

View post on imgur.com

也就是說。”事實”處於最高位階,在任何”假說”、”理論”、”定律”之上。

為何要特別寫一篇文章來說明這件事呢? 因為,我發現這看似微小的差異,其實不知不覺中,影響了我們在接受訊息時的態度傾向。我以下面兩張示意圖來表示:

View post on imgur.com

View post on imgur.com

當新的”事實”出現時,若是和定律、理論、假說之一抵觸的情況下,若依原先的位階排序,直覺下容易傾向先去否定跟忽略位階較低的新”事實”,而堅持心中位階較高的想法理論。然而,若將”事實”的位階修正為最高的話,那麼,當遇到新出現的”事實”時,較容易放下對既定想法的堅持,而試著去調整與建立出新的理論,來同時適應新知的和已知的事實。

或許偶爾提醒自己在直覺上的盲點,有助於自己能更坦然的面對新的事物,與對待別人的發現與看法。

補充:
publish on 2018/01/08

補充:
參考 “拼圖思考法” 一文。以拼圖思考法的角度來看,散落各個角落的”事實”,正是拼圖思考中的拼圖碎片。

補充:

補充:
“快思慢想”一書中,有提到”認知不協調”的現象。

效能瓶頸下的選擇傾向

約是在 2014 年前後,我想通了一件事,但一直遲未將想法化為文字。今天終於静下心來作這件事了,我想要說明的是,為何在某些效能瓶頸的關頭,我會主張作深度分析優化,而非立即性擴充資源緩解眼前的問題。

舉電商網站經營為例,資料量主要有會員、訂單、商品等資料,大致可初估資料的複雜度以 n^3 的速度在膨脹,因此所需的運算需求量也以這速度跟著成長。這可用下方這示意圖來表示:

View post on imgur.com

其中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]. 有趣的是,一個長期追蹤跟解決問題的人,還會遇到上述種種的問題嗎?

曾經遇過的 firefox 與 chrome 的不穩定問題

記得很久之前,(註: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。

View post on imgur.com

從上圖中可以觀察到,Xorg 跟 chrome 的 cputime 在執行到某一個時間點時,就同時出現斜率的變化,跟問題症狀出現的時間也吻合,我這才恍然大悟, 原來禍首是 chrome。而這關鍵證據,也洗清了 firefox 的嫌疑。最後是分析出,是 chrome 有用到 graphic render 加速的功能,關閉後就沒事了。

後來又有一次,大約是 2015/02/20 前後,有更新系統,升級了好些函式庫, firefox 也從 34版升級到 36版,之後就又產生類似的 Xorg reset 的問題。幸運的是,當時我已經建好有觀測數據的機制,再加上有高手在網路上的討論幫忙,最後將分析範圍縮小至 Xorg intel driver 跟 firefox 的 render 加速相關的功能。

View post on imgur.com

其中,由上圖這張當時取得的數據圖中,可以看到 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 在系統升級前後的對照:

View post on imgur.com

從上圖中,可以觀察到 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 大致如下:

View post on imgur.com

View post on imgur.com

View post on imgur.com

View post on imgur.com

View post on imgur.com

關於高雄捷運虧錢的話題

每隔一陣子,關於高雄捷運是不是虧錢的話題,就要反覆再來個一次。
我感到十分厭煩,然而關於自己家鄉的議題,面對紛擾總無法視而不見。

網路上各方有各方的說法,很難分得清楚誰是真知灼見,誰是詭辯。
而且目前網路上查到的資料,多是斷章取義,或是先射箭再畫靶的報導或評論。
想要獲得真相,我想最好的方式就是,自行去取得第一手的資料作評估。

於是,這兩天花了一點時間,以程式抓取數據並後置分析了一下,結果如下:

數據分析結果

高雄捷運 2008/03 ~ 2017/03 的運量趨勢圖
( 單日平均運量,以7日為計算週期 )

View post on imgur.com

台北捷運+高雄捷運 1996/03 ~ 2017/03 的運量趨勢圖
( 單日平均運量,以7日為計算週期 )

View post on imgur.com

以下是我根據上述資料,個人的解讀與看法,如下:

Q1: 高雄捷運搭的人多不多?
目前的每日運量大約是 17 萬人次。
若高雄市人口數以 278 萬來估算的話,每天大約有 6% 人坐捷運。

台北捷運每日運量接近 200 萬人次。
若雙北以 667 萬人口計的話,每日運量約 30% 坐捷運。

Q2: 高捷的運量是否有持續成長?
在 2013 年之後,運量似乎就沒有再顯著的成長了。

Q3: 為什麼高雄捷運的運量上不去?

這個問題,我沒有答案,但我發現到幾個線索:

View post on imgur.com

首先,台北捷運也不是一開始就有百萬運量的。
台北捷運前2年的運量,跟高雄捷運也是差不多的狀況,甚至更少。
但是,在 1998 年底,跟 1999 年底,都各有一次跳躍式的成長。
於是我查詢對照了一下,維基百科上台北捷運的歷史資料。
發現這兩個時間點,分別是:

  • 1998年12月24日淡水線台北車站-中正紀念堂站段、新店線中正紀念堂站-古亭站段及中和線完工通車
  • 1999年12月24日板南線市政府站-龍山寺站通車後

尤其是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

gentoo in docker with systemd

想在 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

歡迎有興趣的人自行取用。

N年後再次提筆Blog

這是個對沉默的人不利生存的年代,當大多數的人的注意力都被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

怎樣的「失敗」才是成功之母?