分享到plurk 分享到twitter 分享到facebook

yenslife (潘駿諺)

簡介

  • 國立成功大學 資訊工程學系 114 級
  • Github: yenslife
  • HackMD: yenslife

2024 Linux 核心設計 春季班 自我評量

成果發表和貢獻

評分: 10

「取之於網路,回饋於網路」,深受網路開源學習資料的影響,貢獻開源專案是我參與這堂課程的目標之一,雖然沒有對 Linux 核心做出貢獻,但我在閱讀老師撰寫的教材時,除了更新過時程式碼外,也提供相對應的解釋,以及我認為對讀者更好理解的詮釋方式。在第一次作業 lab0-c 撰寫開發紀錄的時候,老師在我的筆記問我「如何確保排序的『穩定性』」,“stable” 一詞我只在過去學習演算法課程的時候把定義背下來,但我從沒想過要怎麼確保一段排序程式碼是否為穩定排序。從一開始單純在每個排序元素的成員加上編號,到現在使用陣列來紀錄節點的位址,目前的實作還有進步空間,因為固定長度的陣列沒有辦法適用於任意大小的佇列,可以利用像是 sliding window、hlist 之類的技巧來避免使用固定數值的巨集。不斷和老師討論、修改電子書或是程式碼教材的過程也讓我知道原來把小事情做到好是很重要的,光是留意細節就可以贏過許多人。我認為我在課程教材方面做了不少貢獻,第一次貢獻開源專案的經歷讓深刻的體悟,因此給自己 10 分。

作業/隨堂測驗共筆

評分: 6

我沒有完整地完成每次作業,但是每次作業都有深刻學習及探討。lab0-c 讓我重新認識 C 語言,認知到自身能力不足,以為自己會 C 語言,遇到問題直接原形畢露,根本不算是有學過。提交 commit 的過程被老師提點說要好好撰寫 commit message,考慮到「人在做,Google 在看」所有的 commit message 都是使用英文撰寫,我的英文寫作沒有很好所以都是用 ChatGPT 幫我寫 commit message,這種工具導向去使用 AI 而不是把 AI 當成「神」的使用習慣對我來說很有幫助,不再需要害怕模型輸出的正確性,因為你請他幫忙的內容都是建立在你已知的知識之上,完成任務的效率才會更高。撰寫 commit message 的好習慣也導入至我的大三專題,和組員間的溝通有效率 (好的 commit message 可以節省大量溝通成本),因為我的作業和專題都是公開的,這個習慣也被我實習的主管稱讚 (從沒想過寫程式以外的事情能被稱讚)。以為自己會用 git 了但跟 C 語言一樣,只是以為自己懂了。除了 git rebase -i, git cherry-pick 等實用的命令,在 Homework2 因為探討到 glibc 隨機函式的程式碼,老師教我用 git blame, git log -S 等命令,藉由查看大型開源專案的 commit message 來學習前人實作的程式碼背後的想法,這讓我更重視工程上的溝通以及程式碼的 “Good taste”。不論是作業還是期末專題,我在修這堂課之前都以為自己會花很多時間撰寫程式碼和 debug,但事實是,很多時候我都在觀察別人寫的程式碼、撰寫文件和「思考」,我覺得思考是這堂課的核心,因為思考是需要花時間的,這件事在這個浮躁的時代很少人做得到,很少人會真的把課程教材 (像是原文書) 看完,大家都想要速成直接看到結果。但工程不是這樣運作的,動手做固然重要,但在動手之前的數學推導、統計還有規劃都更為重要。我沒有做完每次的作業,但扎實學習的體驗和成長讓我想給自己及格的 6 分。

期末專題

Linux 核心專題: 排程器研究

評分: 7

過去在學習作業系統排程相關章節時,課本 (恐龍書) 只有提到 round robin, FIFO, MLFQ 之類很單純的排序方法,老師的書《Demystifying the Linux CPU Scheduler》講的是現實世界的排程器,讓我很有興趣,因為期末專題的選擇也有電子書編撰 / 修訂的選項 (ch1, ch2),所以我選擇了這個專題,(當然還有練習英文這個原因)。和老師討論的時候,他說也知道現在的學生很少會把原文書從頭到尾看完,我也是一樣的,所以對我來說是一個挑戰,過程中也需要和目前的 Linux 程式碼去比較,觀察核心開發者的 commit message,並思考其背後修改的意義。我也是第一次看書還和作者討論、檢討書籍的錯誤,過往其實不太會去懷疑課程教材的內容,有什麼吃什麼,可能還消化不良,但是我的專題就是去改課程教材,也讓我在之後看到從網路上的文章,到這種專業的內容,都有自信帶著批評的心態去檢視。我給自己七分,因為雖然有達成目標 (一二章的修訂),但是我的閱讀、看程式碼的速度還不能帶我到後續的章節,所以給自己 7 分。

與授課教師的互動

評分: 8

我跟老師約了兩次一對一討論,第一次 (05/03) 主要討論專題主題的選擇,那時候我說我會選擇電子書撰寫是因為做失敗的風險…一提到風險二字老師馬上提點我:「這麼說是很危險的,風險不是你該擔心的事,而是你的主管該擔心的事情,你要做的是去解決問題。」遇到任務總想挑簡單的做,在乎的風險也不過是成績對推甄的影響而已。不做困難的事情,那就跟其他人一樣,成績也只不過是一個過程,重要的是你能在課程結束後留下什麼?而不是只記得「資料結構 95 分」這種沒有什麼意義的「結果」。第一次的一對一討論老師也順便檢測我對浮點數的理解,談及為何他會這麼重視這樣的「小東西」,因為在一次研討會的會後,老師向一位大師請教了問題,但卻被大師用美式幽默的方式嘲諷到:「你知道什麼是浮點數嗎?」(因為小數點是浮動的,反向思考定點數的概念就知道) 讓我知道我只是以為自己理解了,但細節問到底還是不懂,那就是不懂,更遑論 Linux 核心。為什麼老師會一直強調數學的重要性,因為老師在一次代表公司參與通訊技術的制定研討會中,發現數小時的會議自己連插話的機會都沒有,因為人家談的是數學,是證明。其實我是有點震驚的,因為過去我會覺得像老師、教授這樣的「權威人士」(包含但不限於其他高學歷人士),都可以自然而然的有好的表現,就像我不會質疑一個博士生的數學能力,但我錯了,因為問題丟出來,面試的時候一翻兩瞪眼,不會就是不會,實力不足的事實不會因為你有碩士學歷就被忽略,因為我們要做的是面對真實世界的問題,不能再仗著自己是成大資工就以為自己多厲害。第二次約討論 (06/29) 的內容是針對電子書撰寫,我問老師為什麼不要把舊的程式碼留在書裡,不然之前改的就浪費了。老師就問我我的皮膚不也是每天都在更新嗎?很好笑但也是事實,這也是撰寫程式電子書的難點之一,因為世界一直在變動。

PR 底下確保排序穩定討論的過程也一直被老師說要 “refine your commit message”,一開始覺得有點煩,但如同剛才提到的,開源專案是會被全世界的人看到的,謹慎看待文件的撰寫是很重要的工程素養。我覺得我和老師的討論每次都有很大的收穫,所以給自己 8 分。

所見所聞所感

評分: 10

學期初投入最多時間,後來因為課業、大三專題 (我自認非常認真做專題) 讓我在這堂課的投入時間變少,但是重質不重量,學期初的訓練涵蓋到 List API,我就在編譯系統課程的作業用到了這個方法來實作編譯器,找暑期 / 大四實習面試的期間,也因為 commit message 的撰寫好習慣讓我被加很多分 (事後閒聊詢問主管,他說這可以看出一個人的嚴謹程度和重視溝通的特質,而作業讓他覺得我有「扎實學習」),也因為這堂課讓我第一次體驗到什麼是貢獻開源專案,原來很小的貢獻也是一種貢獻,深入去瞭解內容很可能會找到貢獻的機會,能為世界用自己的專業貢獻一點點東西的感覺真的很不錯。

〈因為自動飲料機而延畢的那一年〉是一個資訊工程系學生嘗試做出自動飲料機的過程,過程中和不同領域的人溝通合作,最後成功做出來和當初構想完全不一樣但是可以運作的飲料機。我覺得老師想讓我們讀這篇文章是想告訴我們,真實世界的問題真的和在學校學的很不一樣,不要太看得起自己。

你最大的問題在太害怕失敗了

青春很貴,你也知道實習會發生什麼事,公司不會指派重要的工作給你,他們只會指派低風險的工作,你學習到的東西並不會比你現在多。你該學習的不是看到事情要完蛋了就去避免失敗,而是應該學習如何處理與承受失敗,你才能變得比以前更強大。

對呀,我是從什麼時候開始太害怕失敗到選擇期末專題的主題也是一個小題目,老師說學生時代就要做難的東西,這種東西才有比較性,如果現在就不行了,那以後背了房貸車貸小孩哭著要上小提琴鋼琴的時候,我該怎麼辦呢?我覺得很幸運我的實習的公司是一間目前在產品規劃階段的新創,很多東西都要從頭開始,有很多問題是沒有答案的。雖然說是從頭開始,但就像老師說的,離開學校就很少有機會從從第一行程式碼開始開發了,一定是基於前人的足跡、開源的專案,去修改、去維護。

這堂課帶給我的基礎素養,才是真實世界期待的,也是除了學歷以外能夠與其他人拉開距離的東西。

綜上所述,我認為我的投入以及收穫可以讓我拿到 10 分。

自我評分

方案 B: 1 + floor(GEOMEAN)

(10 * 6 * 7 * 8 * 10) ^ (1/5) = 8.04021858

1 + floor(8.04021858) = 9