2025q1 Homework5 (assessment)

contributed by < Andrushika >

因為自動飲料機而延畢的那一年 - 閱讀心得

以下採取佳句節錄以及自我反思的紀錄方式：

我開始透過朋友詢問，試圖在整個交大中尋找懂機械設計和製造，而且對自動飲料機有興趣的同學。然後我發現一個原本以為只有在資工系發生的現象，那就是「資工系的學生不會寫程式，機械系的學生不會做機械」

看了除了資工系的學生不會寫程式，機械系的學生不會做機械，現在又多一條電工系的學生不會焊電路，這世界到底怎麼了啊。

看到這段的時候深有同感，為何大學上完四年，那麼多學生還會對職場感到這麼焦慮？老師也曾說過，若大學教育足夠完備，那企業 HR 應該會排在學校門口等學生下課、搶人才對，但這件事沒有發生，有什麼是需要改變的？

…這些因素產生的問題有沒有嚴重到需要更改設計，就只有做實驗才知道。因此大部分的時間我都在做實驗。把機器接上管子並打氣加壓，控制電磁閥通電的秒數，用超大的量筒測量體積，重複數十次取平均。接下來更改閥件接法，重複同樣的流程再做一遍。透過不斷的實驗，才能知道機器是不是如同預想中運作。

之前開發過不少應用層專案（前後端、App 等等），通常只要寫出來符合預期、好維護、測試會過就好。因為程式的行為不會改變，自然也不需要做什麼實驗測試可靠性。後來發現是因為我做的東西都太小了，修了這門課之後，作業都會不斷強調實驗的重要性，透過實際的數據來解釋現象、而非感覺。例如討論 memory barrier 的時候就把 compile 完的 assembly 拿出來討論、探討 kernel module 效能瓶頸的時候就用 ftrace 追蹤；這種追根究底的方法，讓我在開發的時候心中踏實許多。

我不能再無腦地相信這個傢伙了。每改一次設計，就得把設計圖面送到加工廠，然後等待一週的時間，再從工廠取加件回來。雖然工件本身材料不貴，但是時間實在是拖太久。

托數位孿生技術的福，這種機械都可以先在物理世界中先進行模擬驗證可行性，再實作出來。現在的我幾乎無法想像那種每次都要重印零件的痛苦。

現實如同真理般，給予和狂妄自負的傢伙相對應的絕望，對於沒有準備好的人毫不留情。

你不能現在就放棄，要是現在就放棄的話，你這輩子日後遇到這種等級的困難，就只會想逃避而已。

你該學習的不是看到事情要完蛋了就去避免失敗，而是應該學習如何處理與承受失敗，你才能變得比以前更強大。

這幾句話完全命中我從之前開始做專案，到這學期在閱讀課程教材時的心態、也把我打醒。難道我每次看到這種等級的困難就要逃嗎？這樣我一輩子遇到這種困難時都解決不了。我發現我似乎一直處在「愚昧之峰」、因為「積極避免失敗」而充滿自信。最近才開始發現資工的世界中，事情遠遠沒有那麼簡單。

我們將秤冰塊的機構固定好後，將其傾斜，希望落入的冰塊會從尾端開始堆積。另外擋板可以避免冰塊超出支點，接下來，由我負責檢驗該設計下冰塊和荷重元產生的訊號是否有正比關係，誤差是否在可接受的範圍內。於是我便重複「加冰塊、倒冰塊、測量訊號、紀錄」，做了超過480次。

統計學真的在這裡用上了，完全沒想過這些知識竟然會被用在量冰塊上…

但我經手了這台機器的每一個細節、我知道每一個零件存在的理由、每一個設計背後做出的取捨，我比任何人都清楚這台機器還有多少問題，茶垢可能會卡在接頭的縫隙、冰塊的定量機構絕對還能再改進、管線過脆容易折斷……我可以列出上百個問題，機器現在能做到的每一件事，都是用一次次試誤換來的取捨。

好像能稍微理解「自幹」的浪漫。我們在開發應用層軟體時，常常使用別人開發好的框架，我所做的也只是利用這個框架去客製化自己的需求。特別是在 ChatGPT 這麼強的世代，解決簡單的問題常常已經不需要了解造成的原因、不需要實驗；只需要詢問、然後照他說的做。開發過很多應用，我到現在仍無法自信的說，我理解過程所使用到的那些工具、我理解 de 過的每個 bug 的解決關鍵。像是我長了很多虛肌肉，結果的成品看起來令人滿意，但走到終點的過程很是心虛。

這學期的期末專題，我被分配到了「從無到有打造 container」。收到這個題目時，雖然沒辦法在短時間內達成想要貢獻的期許，但心中莫名的踏實。我相信只有從最底部了解每個細節、每種機制存在的理由與取捨，才能把所學變成自己真正擁有的。

課程到目前為止的心態轉變

我覺得我到目前為止的作業完成度不好。

在第一、第二周時，都稍微還能跟得上，每天上課完就讀教材、寫作業，一天可以花 13 小時在寫作業，因為想要把這些事情快點做完，才能放下心中的重負。
作業的要求看起來很多，而學期初的我很討厭有一大坨事情 pending 還沒被處理的感覺；我想可能是因為責任感的驅使，我會因而覺得很煩躁。所以到後來作業的要求越積越多，我嘗試做的事情是把所有題目稍微看過一遍、每樣題目要求做一點點，然後開始在 hackmd 寫一堆字、貼程式碼；看著滿滿整頁的 hackmd，有時候還會產生一些透過偽努力產生的成就感。

過了五、六周，我心裡面的罪惡感開始萌芽，甚至有些想退選、放棄的念頭。因為我發現，隨著新的作業不斷發出來、事情做不完，我想「早點完事」的心態沒有盡頭；就算真的按下了繳交鍵，心中也不踏實：因為回頭看自己寫的東西，我沒辦法自信地說出我學會了些什麼。但最近稍微想開了一點，因為以前的自己沒遇過這種等級的困難，所以才不習慣掙扎。現在遇到了、開始感覺到痛苦了，我想這是大腦有在發育的證明，是一種成長痛。

在看了幾位同學的作業還有課堂討論後，我發現有些人會選擇針對一個議題作深入的研究：例如 lab0-c 中針對 queue.c 的函式實作，還會加上計時、繪圖等量化分析，透過科學的方法來驗證想法是正確的。

看了這些別人的成果，總覺得這樣的產出才是自己想要的，為了交差而交差實際上對我一點幫助也沒有。我打算從這之後開始，選擇慢慢的把每個題目做深、詳細理解。放慢腳步，慢慢走一定會走到終點。

期末專題的 brain storm

1. 閱讀到 vax-r 同學使用 ML 分析 CPU 排程策略的報告覺得很有趣、數據分析也很清楚，讓我也想做一些使用 ML 協助 kernel 分析效能的題目，包含但不限於 CPU scheduling。
   除了作者提到的效能評估指標外，可能可以針對這些方向作一些延伸：
   • cache hit/miss rate - 特別是在 task migration 議題上，頻繁更換執行的 CPU 可能不是好事
   • I/O waiting time - 實驗時若混雜了大量 CPU bound 和 I/O bound task，那麼評估時是否兩種 task 的 metric 是否都應該考慮，而非只專注降低 CPU bound task 的 turn around time？
2. Docker 在現今軟體開發中是不可或缺的工具，我曾做過一些 full stack 開發與部署，也深深的體會到這點。雖然耳聞過 namespace 概念，但我想試試深入理解他的實作。
3. ItisCaleb 同學去年做的「透過 Netfilter 自動過濾廣告」我覺得很酷，也很貼近我們的日常生活需求（不想看廣告）
4. 想起了自己曾在 SITCON 聽過一個寫射擊遊戲外掛的題目，聽起來很好玩，有沒有機會從 kernel 層面繞過遊戲的外掛檢測機制？（還沒有深入了解裡面的原理）
5. 我很喜歡一款多人射擊遊戲 —— Apex Legend。該遊戲有一個平衡機制：因為玩家可能同時來自家機 (XBOX, PS4, Switch) 或 PC，所以有些玩家會使用遊戲搖桿遊玩、有些則使用鍵盤與滑鼠。官方認為使用搖桿的遊玩難度較高，所以使用搖桿的玩家可以獲得系統提供的輔助瞄準。
   有沒有機會可以自己實作 device driver，將滑鼠的輸入訊號轉換為遊戲搖桿訊號，藉此騙過遊戲的偵測機制，讓本來就佔有優勢的滑鼠玩家可以獲得輔助瞄準？
   （不道德，但我非常有興趣）
   • 由於當前多數提供「輔助瞄準」的遊戲都並非從 dev/ 讀取輸入，而是讀取 HID 層，所以光寫 device driver 模擬輸出可能無效。
   • 理想的作法是攔截滑鼠、鍵盤輸入，並轉譯為搖桿訊號，之後外接 Respberry Pi 到電腦、模擬 USB HID report。
6. 目前的大三專題在做多視角幾何三維重建的題目，會同時間使用很多相機進行拍攝；此時會遇到相機不足的問題。或許可以自己實作 device driver，讓我們手邊就有的手機、平板鏡頭變成電腦可以使用的 camera input。
7. 有什麼題目可以從我現有的技能樹延伸？
   • 前後端
   • Android App 開發
   • ML, RL 的應用（還沒有能力進行底層模型數學推理，只能應用）
8. 前幾天看了老師分享的，有幾位和我同屆的同學成為了 Apache commiter，有點激勵到我，覺得他們的貢獻成果是我想成為的樣子。我參閱了源來適你社群有 mentor 的開源專案，其中我對 KubeRay 專案感興趣：這個專案負責 Ray 工具與 k8s cluster 的整合，協調 Ray Service, Ray Worker，為當今的 AI infra 相當重要的一塊。使用者將可以用 cluster 訓練模型，且用簡單的介面實現，大幅提升訓練效率。
   因為自己對系統軟體有興趣，我為自己設下了一個目標，希望可以在畢業之前（還有一年），對這個專案投入貢獻。同時這個專案和我於第 2 項所提的容器化技術相關，希望期末專題的選題可以先為貢獻的目標打下基礎。

   （更膚淺、現實一點，這在履歷上是一大亮點，為了賺錢）