Chiu Chi-Kuan (邱繼寬)
簡介
國立成功大學 資訊工程學系 115 級 (2021 ~ 2025)
GitHub:
devarajabc
HackMD:
devarajabc
2024 Linux 核心設計 春季班 自我評量
自我評分
- 成果發表和貢獻: 10 分
- 作業/隨堂測驗: 10 分
- 期末專題: 6 分
- 與授課教師的互動: 10 分
- 所見所聞所感: 10 分
總分:使用方案 B: 1 + floor(GEOMEAN) = 1 + floor(9.028804514) = 10
Linux 核心和相關專案貢獻
《Demystifying the Linux CPU Scheduler》:
修改 Fixed point arithmetic 84b2454
修改 2.2.1 Early Linux Scheduler 3b1e731
這部分我給自己 10 分,藉由改善《Demystifying the Linux CPU Scheduler》可以使未來的同學在學習 linux scheduler 的過程更加順利,間接推動科技發展。
與授課教師的互動
- 5/11 一對一討論
- 5/31 一對一討論
- 6/5 一對一討論
- 6/16 一對一討論
- 6/18 一對一討論
- 6/22 一對一討論
- 6/24 一對一討論
- 6/28 一對一討論
- 7/2 一對一討論
評分 : 此項目我為自己打 10 分,在一次次跟老師討論的過程中我逐漸意識到自己的錯誤並努力改正,這種精神我認為值得 10 分
以下是我的學習與成長:
放下面子,誠實面對自己: 一開始在跟老師溝通時常常有易無意地藉由一些「話術」來掩飾自己的不足,或是先把自己講的很爛,想讓老師把期望降低,進而避免被罵。 然而這樣對討論一點幫助都沒有,也忽略與老師溝通的目的就是為了要變強,不是為了什麼可笑的尊嚴,此外老師在教育現場打滾多年,這種雕蟲小技早就看膩了,掩飾的越賣力反而越滑稽可笑。 被老師點破之後我便努力調整心態,放下完美主義並客觀地描述自己面臨的困境,才能讓老師知道如何協助我,進而「變強」。
學習如何問問題: 在學習「誠實面對自己」之後,另一個很重要的課題是「如何問問題」。 一開始問問題時常常犯一些錯誤而不自知,例如無法明確點出問題點,導致老師根本搞不清楚我要問什麼,造成溝通效率低下。 或是問一些空泛、虛無飄渺的爛問題如「我該怎麼學?」、「未來方向怎麼走」等,這些問題沒有標準答案而且因人而異,毫無意義。 這些錯誤被老師糾正之後我便練習在問問題時要提出具體請求,並在問問題之前反問如果是自己會如何回答,藉此來讓自己的問題更清晰明瞭。
學習如何討論: 在學習「如何問問題」之後,「如何討論」變成我下一個重要的課題。 我在討論的初期都沒提供「討論的素材」,例如某個開發者的訪談或是某本書的編排方式,然而老師不是神,沒辦法聽到關鍵字就能在腦袋裡冒出所有資訊,在沒有充足的準備之下老師就需要花更多時間精力「釐清」我想討論的內容,使討論效率大打折扣。 此外我也沒有掌握「議題」的大小,有些議題的跨度很大,要考慮的面向很多,就像機關槍式的連環炮提問一般,不知道要從哪裡開始討論,妥妥浪費時間。 在被老師糾正之後我練習在討論之前就提供好要討論的素材並附上我的「見解」,使老師在討論之前可以清楚了解我想討論的內容,開會時便能直奔主題。 此外關於「議題大小」的部分我練習將大議題拆解成「最小單位」,避免讓議題之中又包含其他議題。
作業及quiz共筆
這部分我給自己 6 分,4 分在於我在 lab0-c 中有成功完成 queue.c ,使其滿足自動評分標準。 在實作 lab0-c 的過程中我學習使用過去一直逃避的 git,以及「正確」的程式專寫流程:應該先詳閱資料並瞭解相關規格,而非憑感覺亂寫。 此外我在既有的基礎下新增 worst-case generator Commit 16f69b2,使我能檢驗 merge sort 在最差情況下的運作狀況。
另外 2 分則是在 quiz1+2 中,我發現老師在測驗裡提供的 timsort 原始碼中, “find_run” 沒有遵守 2 的冪的原則也沒有確保每個 run 的長度不小於 minrun ,於是我 提出改進方案,但沒有實作出來,所以只給自己兩分。
Linux 核心期末專題
一開始在閱讀 《Demystifying the Linux CPU Scheduler》 的過程中我感到非常痛苦,每個單字都會但合起來就看不懂是什麼意思,還洋洋灑灑列了一整頁的問題(詳見 研讀第 1 到第 6 週「課程教材),一開始以為是自己英文能力太差,但其實是因為這本書是與不同年代、不同作者所拼貼而成,造成章節之間的連貫性有很致命的缺陷,因此我的專題: CPU 排程器研究便著重於改善 《Demystifying the Linux CPU Scheduler》,使其內容更通暢。 以下是我在這學期的貢獻,在學期結束之後亦會繼續投入:
- Refine section “O(n) Scheduler”
- Refine section “Early Scheduler”
- Improve section “Fixed point arithmetic”
詳見 《Demystifying the Linux CPU Scheduler》重點提示
此外考慮到 linux 是個不斷進化,猶如星之卡比一般,必須建立統一的書寫結構,方能使後繼的修改者能方便增補。
具體內容如下:
歷史事實使用過去式,內容包含對「過去」的排程器的定性分析,以及此次變革旨解決什麼問題和此版本面臨的問題,利用時態的變化來強調其演變。
其餘部分使用現在簡單式,例如說明演算法,資料結構等,使用現在簡單式能方便後人收錄開發者的 commit message 。
這部分我給自己 10 分,五分是給肯定自己在如考古學家一般在網路上翻找上古的資料並進行彙整,另外五分在於我將彙整後的資料與既有的內如進行編排,使讀者能更輕易閱讀。
所見所聞
我認為這學期的成長可以分成對內與對外,對外請見 「與授課老師互動」,而對內的成長在於心態與時間管理。
在心態上,我面臨的考驗是要在短時間內吸收大量的知識,克服其中的焦慮與徬徨的過程是我認為最重要的成長。 舉裡來說,為了要暸解分時多工,我遵照課程建議閱讀了 cs:app 第八章與第十二章,沒想到來回看了三次還是看不懂,各種名詞與概念有如中世紀的蒙古鐵騎一般把我踩的屍骨無存,倒在地上的我看著時間一天一天過去,作業進度依然卡在泥濘之中,這讓我意識到自己在學習上的盲點,在細節上鑽牛角尖,見樹不見林,在意識到問題後我只好將 cs:app 擱置一邊,改去閱讀 Linux 核心設計: 不僅是個執行單元的 Process 和 UNIX 作業系 fork/exec 系統呼叫的前世今生,然而閱讀完還是對相關概念一知半解,蒙古鐵騎換成中文版依舊能把我踩死,搞得自己非常焦慮,此時我才意識到自己除了愛鑽牛角尖還太想要「速成」,總是想著要「一步登天」,兩種矛盾性格的拉扯造成意想不到的焦慮感,因此在閱讀時特別有感觸,感觸在於我在男主角身上看到我自己的缺點與盲點:我跟主角一樣在錯誤的地方卡住、一樣因為害怕失敗而綁手綁腳(尋求美德的幻覺來隱藏自己的惡習)、一樣喜歡自己硬幹,重新製造輪子。不過男主角畢竟是男主角,在意識到自己的錯誤後就立刻改正,最後也成功完成目標,這是令我嚮往的,我也想當男主角。
於是我決定老老實實地觀看交大資工曹孝櫟教授的〈作業系統設計與實作〉線上課程並搭配閱讀 《Demystifying the Linux CPU Scheduler》,沒想到卻意外開啟自己的期末專題。
此外這堂課也粉碎我對「學習」的認知,過去的「學習」是靠著小聰明與學長的考古,在考前一個禮拜就可以搞定半學期的課程,然而這堂課對「學習」的要求遠遠超過「寫出正確答案」。 這堂課要求學生當個「科學」的人,要閱讀第一手資料,不要把網路上的「科技農場文」視為珍寶,在高等學術殿堂上道聽途說,然而就算閱讀文獻是也不能照單全收,不是實作出來就沒事了,要提出自己的「洞見」並佐以「數據」說明,此外這一切都要基於「解決真實世界的問題」之上,不是文人的閒雅生活中的糜糜之音。
然而要當個有數據、有論點、又能解決「真實世界的問題」的人絕非易事,糟糕的生活型態(aka 沒!紀!律!)讓我難以負荷如此大的學習量,只能不斷退選其他必修來「擠」出時間,直到剩下 13 學分才意識到事情的嚴重性:我的時間管理能力很糟糕,以至於我的做事效率很差。
於是我鼓起勇氣去看身心科改善睡眠問題,讓我有更多的時間學習,並且在讀書時強迫自己每半個小時就要問自己剛剛學會的什麼,避免陷入思想的死胡同而耽誤後續的工作,在必要時要選擇壯士斷腕。
很感謝老師的一次次「震撼教育」把我從同溫層的幻想世界拉出來,讓我認識到真實世界的樣子,在這過程中的學習與成長我給自己 10 分,10 分在於我沒放棄,數度想退選都撐下來了(不過其他科就抱歉啦),而且在遇到挫折後也沒有擺爛,而是選擇適合自己的方式作出貢獻。