waning2015-10-14 18:46:45終於知道自己的電腦渣了
知乎使用者2015-10-14 21:37:28這個問題問的 excited！
等我開下 VMWare 來 build 個 debian 核心出來。
——
10:16:41 EDT
開始 build，CONCURRENCY_LEVEL=16， VMWare Workstation 最大隻能支援到16個核心
去吃早飯
10:31:28 EDT
build 完了，一共將近十五分鐘，刷了會知乎，還沒去吃早飯。偷懶沒裁剪核心也沒 patch，直接拿 repo 裡面 3。16。7 的 source 來 build 的
體驗就是——沒有什麼體驗。build 期間幹啥都行，反正不缺 cores。
Hint: 用 tmpfs 的話可以讓你嚐到幸福的滋味
「已登出」2015-10-18 07:55:11有一次開會，會議的演講非常的Boring，我混混欲睡，轉頭看見旁邊的人在用Mutt寫郵件，落款是-Greg KH，一下子精神起來。然後我就在那裡看了半個小時看大神是怎麼處理每天那麼多的Patch Submit的。
其實Greg的處理郵件模型和我們是很像的：
首先在mutt中tab找新郵件，看到patch，有可見問題就回復，沒有就儲存到一個mbox中，用screen切換到另一個視窗，am，make -j （基本上都是隻有一個字母的指令碼，但從輸出就知道他在幹啥了）
切換回來，接著看下一個PatchSet，有些是討論的，立即回覆。回覆的時候幾乎沒有客套，有話說話。他的處理過程給我一個強烈的感覺，就是如果你再多說兩句不入正題的話，Greg就該把你的郵件刪除了
生成下一個mbox，回去看看編譯完了沒有（我很懷疑他用了遠端服務來編譯，因為完成得特快（當然，中間編譯本來就快，但快到這個地步，完全不像他那個Chromebook可以做到的），然後立即切換回來答覆，apply下一個patch set，接著編譯
如果前一個patch過了，再切換一個視窗（都是screen視窗），apply到下一個分支上，在那個分支上接著驗證試驗。
所以，你說等待編譯結果的過程是什麼體驗，那就是“沒有時間來體驗”：）
向晨2015-10-29 12:14:46這個問題還不如問等待buildroot整個編譯完是啥體驗，自從我開始玩buildroot，我都覺得make linux是挺快的步驟了
Leedy2015-10-31 00:22:24公司有兩臺伺服器專門用來編譯（公司窮，不能每人一臺），make -j 48 bzImage 大概30s就可以，沒試過tmpfs或ccache。
