10 questions for every migration

Q: 為什麼要用新的?Why change to new service?

Q: 新的有那些功能? 解決那些問題?What features does new service have? and what problem will it solve?

Q: 新的如何上手使用?How to use new service?

Q: 舊的用戶如何切換至新的工具?How do old users switch to new service?

Q: 舊的資料如何備份並匯入新的?How to migrate old data to new service?

Q: 舊的使用方法如何一一改用新的方法處理?How to replace each old usage with new service’s usage?

Q: 有那些舊的功能是新的没有的?可接受?What old features are not covered by new service? Is it acceptable?

Q: 若轉換成功,之後如何讓舊的逐步退場?If migration success, how to deprecated old service?

Q: 若轉換失敗,之後如何回復到舊的方法?If migration failed, how to rollback to old service?

Q: 新的是否有秘密鎖定的問題?如何避免?Will we get lock-in problem with new service? How to avoid?

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

註: 僅概念示意圖。

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

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

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

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

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

其二,嘗試取得統計事實

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

Гидра сайт | Официальная ссылка Гидра : гидра магазин | гидра маркет : hydra onion

Гидра сайт | Официальная ссылка Гидра : гидра магазин | гидра маркет : hydra onion

Мы рады вас приветствовать на сайте Гидра, здесь вы сможете найти ссылки и зеркала на официальный сайт Гидра,
а также узнаете о магазине Гидра и её деталях

Рабочие зеркала Гидра – ссылки на гидра маркет

Вынуждены отметить, что в последнее время нас очень часто пытаются одолеть различные фейки, которые являются паразитами нашего сайта и мало того, что их количество постоянно растет, они постоянно атакуют на ДДОС атаками, большинство из которых нам не страшны из-за большого опыта на рынке даркнета и опыта нашей команда, но некоторые иногда пробиваются нашу защиту и в такие моменты нам требуется время на восстановление, когда такое происходит и вы не можете войти на свою привычную ссылку гидра, мы хотим чтобы вы были осведомлены и добавили данную статью себе в закладки чтобы иметь запасной способ как попасть на сайт гидра, если какие-то из зеркал находятся в ауте, официальный список наших зеркал и ссылок на сайт гидра:


Также предоставляем вашему вниманию ссылки на онион гидру, если вы наш старый пользователь, то вы знаете что на онион ссылки гидра можно попасть только через определенный браузер – Tor браузер, поэтому если вы новый пользователь, то обязательно скачайте Тор браузер, используя его вы делаете своё пребывание в сети намного безопаснее, ссылки на гидра онион:

Теги:гидра, гидра сайт, рабочее зеркало гидра, гидра ссылка, как зайти на гидру, гидра маркет, гидра магазинспособ обходаобход блокировкитор гидрагидра анионрабочая гидрагидра сайт в тор браузерегидра правильная ссылка

Помощь пользователю и статьи по сайту Гидра

Мы предлагаем вам окунуться в мир даркнета и посетить проверенный временем и испытаниями, самый крупный магазин запрещенки Гидра маркет, мы довели покупки на нем до полного автоматизма и безопасности, так как при покупки чего-либо в магазине гидра, деньги которые вы перечислили за товар не дойдут до продавца пока покупатель не подтвердит получение товара, то есть в случае ненахода вы можете обсудить вопрос с продавцом и в итоге он обязан сделать перезаклад или деньги вам вернуться, если не удается решить вопрос с продавцом, то смело зовите модератора сайта гидра в беседу и он обязательно разрешит ваш конфликт. Как уже упоминалось, все сделки в магазине гидра происходят автономно и вам не нужно ждать когда продавец будет онлайн, это очень удобно.
Перед первой покупкой на сайте вам необходимо создать аккаунт путем краткой регистрации на сайте, после чего вам необходимо пополнить личный счет на сайте, а именно приобрести биткоин и приступать непосредственно к покупкам, намного подробнее вы сможете узнать об этом в данном мануале ссылка на мануал.

На сайте гидра полным-полно различных мануалов по сайту гидра полный список вы можете увидеть здесь: ссылка на статьи, также новости на сайте постоянно обновляются, вы можете наблюдать это тут. На сайте Hydra вы сможете найти ответ на любой вами заданный вопрос, мы стараемся держать вас в курсе всех новостей касающихся hydra.


Теги: ublhf vfufpby, ublhf ccskrf, ublhf cfqn, ublhf jybjy, ublhf cfqn d njh ,hfeptht

效能瓶頸下的選擇傾向

約是在 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分鐘的口頭解釋, 其實是不斷地省下更多的時間和耐心. 如果, 我寫的內容能回答某些常見疑惑或月經題的話, 或許我不只能幫自己省時間,還能幫别人省時間.

其五,整理舊文時,偶爾意外發現一些早已忘記的生活點滴。坦言,讓別人看到自己真實生活的不同面貌,還真會有點不自在,但回顧曾留下的紀錄時,往往都還是慶幸當初有紀錄下來的。這些紀錄,讓我在這個被快速遺忘的時代中,好像還擁有點什麼一樣。

以上,大致寫下了這次復筆的幾點想法,希望未來的自己感到迷惑時,能再回頭看看一下當時的心境。

加油!