雖然已經是隔了兩代的舊產品，但是我因此勉強能負擔（除了 GPU 我還得連帶買一顆足瓦的 PSU）；且 12GB VRAM 雖然比上不足，比下仍多了些餘裕。

原本我覺得租用 Google Colab 比較省事，但是以我的資料量，Google Colab 不但 GPU/TPU 額度消耗的快，那種在遠距操作下不夠順暢的體驗也不甚好，於是我還是想要回到自己的機器上設置一套機器學習的環境。

硬體裝好後，開機卻沒辦法進 display manager（我使用 SDDM），原本以為 nouveau 應該是至少基本能用。無奈只好重開機進 single user mode (aka recovery mode)，然後參考 Debian Wiki 安裝 Nvidia 釋出、但由 Debian 打包 dpkg 的驅動程式。

裝好之後 SDDM 終於能正常顯示了，然而進 KDE Plasma Wayland session 會有嚴重的遲頓現象，唉，只好再退一步，捨 Wayland 回去使用 X11。

接著又發現 TensorFlow 與 PyTorch 找不到 GPU/CUDA 裝置，原本以為是 CUDA 版本過舊，但是折騰了一個晚上後，才發現是 nvidia_uvm kernel module 沒有載入的關係。

執行 nvidia-smi 查看 NVIDIA System Management Interface 資料後，會發現 nvidia_uvm 被載入了，TensorFlow 與 PyTorch 也因此能找到 GPU/CUDA 裝置。

但是每次都要手動執行 nvidia-smi 也太惱人，於是新增 /etc/modules-load.d/nvidia-uvm.conf 把 nvidia_uvm 列入，讓它能自動於開機時載入。

2025.11.23 更新：因為執行 apt upgrade 時更新了 kermel 版本 6.17.8+deb14-amd64，結果 linux-headers-amd64 與 nvidia-open-kernel-dkms 不知怎麼地爛了，DKMS 無法編出給這個版本的 kernel modules，乾脆改用 NVIDIA installer 安裝驅動程式 580.105.08。

在這個 AI 大瘋潮時代，Google 大可使用更好的威脅偵測模型去處理惡意程式的問題，去加強他們現有的 Google Play Protect 防禦能力。

這在古早古早 DOS 時代的防毒軟體像是 ZLock, Tracer+ 就已經採行「偵測異常行為，而不只是單純掃描病毒程式 pattern」了。

當時礙於硬體能力，這些軟體大概也只能正面表列一些有限的異常行為態樣，但是表現就已不俗；如今即使一台入門級的手機，CPU 運算能力也遠遠超過那些老 PC，還加上可以透過網路協助處理。但是 Google 他們在此處不用人工智慧，而用工人智慧，企圖把技術責任轉移為法律責任。

這難道不諷刺嗎？

要上架 Google Play，你原本就要註冊、繳費、驗證開發者帳戶，這像是進駐市集、百貨公司做生意，合理。

但是現在這個「全境實名驗證開發者身分」卻要求你即使不在 Google Play 上架，你還是要註冊、繳費、驗證開發者帳戶（把你的官方身分證明、法定地址證明都交出來，視情況還會公開揭露），然後你 build 出來的 APK 還得要用 Google 發出的憑證簽署，不然就無法在用戶的手機上安裝。

Google 聲稱這樣以身分驗證要求可以減少惡意程式散布、危害使用者；但是誰來跟我說明一下，我身為開發者，誰來保護我不被瘋狂用戶騷擾、威脅？

且你相信赫赫有名的大公司（姑且想成更注重商譽），就不會在其 App 產品裡作惡？

或是你覺得在 App 裡不慎用了一隻懷有惡意的第三方套件，出了包，是 App 作者存心如此？

再說一次，把技術責任轉移為法律責任，這樣真的很荒謬。

BEAMS RECORDS Clear Portable CD Player

透過日本好物調查局訂購，前天收到商品了，外觀確實有 Y2K 的風味，致敬當年還是窮大學生時買不起的初代 Apple iMac。

音質…まぁ…直接接耳機會聽到惱人的低頻雜訊 (buzz/hum)，感覺是音訊輸出電路的推力太強，預設 20 的音量也大到快毀掉我耳機（與耳膜）了，調降到 04 才終於算是能好好聆聽 CD，然而低頻雜訊仍然在。

自己的解決之道是製作一條衰減器，這樣不但雜訊被濾除，預設音量 20 也不會太過猛烈。

除去雜訊之後，感覺音質中規中矩，當然不比高級音響，但是符合這個價位的表現，且防震能力不錯。

承續〈當你在開源社群熱心過頭，就會有人認為你很好拗，或活該被拗〉、〈為了找工作，而製作一個能力展示開源專案，是個壞主意〉這兩篇。

我覺得別人對我有些誤解，但是又不知如何解釋。直到最近，我才因為想起一段往事，比較能夠透過類比，來表達我的想法。

大學時，我原本有個交情還不錯的同學（本文且以「A 子」代稱），後來因為一場誤會，就疏遠了。

誤會是如何發生的呢？是因為我有次在與 A 子聊天時，稱讚 A 子在超商打工「真的很厲害」，但是在 A 子聽來，我好像在取笑她，於是很生氣。

那時候的超商店員，需要懂的事情就已經包山包海了，更別說是現在。所以我那時是真心覺得她很厲害，光是要我記櫃台後面陳列那一整片香菸的俗稱、通稱，我都辦不到了，遑論還有那一大堆服務項目與作業流程。

直到畢業，直到現在，我都沒能與 A 子好好道歉。

其實那時候我就明白了，A 子「真的很厲害」的原因是：

她如果無法「那麼厲害」，半工半讀、自力更生的她，生活就會難以為繼。

回過頭來看看我，我如果無法把我的能力展示作品（aka 樸實注音鍵盤）做好，我就沒有機會可以接到工作。

把鍵盤鍵帽刻好，考慮排版的平衡、對稱，嚴格到以像素為單位在計較，每每讓眼睛相當疲憊，甚至疼痛不適，並不是什麼「手作職人精神」在驅使我這麼做。

我只不過是想混口飯吃。

當然，你可以覺得我做的工，並不值得我喊的計價方式，這是你的自由。

自從我果斷決定放棄做 Android App 開發，其實我也否認（或確認）了自己在這市場上的價值、斤兩。

在這裡講出來，也只是想讓自己感覺好過一點。

承續之前提的〈為 Samsung Galaxy Tab A7 Lite (SM-T220) 刷寫 GSI 以更新 security patch level〉，我想自己 build 一份 system image。

找到行文當下 Android 14 最新的 security release 是 android-security-14.0.0_r22，看 commit 時間，應該是對應到 ASB 2025-09-01。

抽查了 sync 下來的程式碼，幾個 ASB 2025-09-01 所列的 CVE patches，確實都打了對應的修正。

但是 build/core/version_defaults.mk 裡寫死 PLATFORM_SECURITY_PATCH := 2023-10-05

編出來的 system.img 在 DSU 裡跑起來，也就傻傻地如實回報 Security Patch Level 是 2023-10-05，但是程式理應都已修到 2025-09-01。

誤會了，於是又再重新建置。心累。

而且不禁懷疑，如果 PLATFORM_SECURITY_PATCH 變數值任人填，那可信度何在？