自從 3.4.5 版後，改了一些地方：
rust-toolchain.toml 自動安裝所需的 Rust toolchains。
剛剛把 journalctl -f 掛著觀察系統有沒有什麼地方需要維護的，發現 rtkit-daemon 一直吐 Supervising m threads of n processes of o users. 的 logs 洗版面，有點惱人，找了一下解法：
sudo systemctl edit rtkit-daemon.service[Service] 段，新增一條設定 LogLevelMax=2。記得要寫在 ### Edits below this comment will be discarded 這行的上方，不然是不會存入變更的，我犯了這個蠢。sudo systemctl daemon-reloadsudo systemctl restart rtkit-daemon.service這樣 log level 小於 2 (critical) 的就不會輸出。
之前試著將這台 Xperia Z3 Compact (D5833) 刷寫 postmarketOS，刷機過程雖然順利，然而當 postmarketOS 開機畫面閃過之後，便是無消無息的黑色螢幕。我大概可以猜到這是很典型的卡在 initrd 或 kernel 某個地方，但是確切是什麼地方，還是得想辦法查得，不然我原本想要有一台 postmarketOS 的實機以方便開發上面的應用，就無法如願了。
還好某段時期的 Sony Xperia 對開發者很友善，該提供的技術文件、bootloader 解鎖服務、UART 接點都公開給開發者利用（撰文當下的 2025 年，Sony Xperia 似乎已經不再這麼積極推動這項 Open Devices 專案了），我的 Xperia Z3 Compact 就在這段時期的產品線裡，可以輕易獲知如何透過 UART 接上 serial console，取得非常早期的開機時資料。
GND 是還好，但是 Rx 與 Tx 的焊點真的很小，不使用 OK 線的話很難焊上去。
此外，板子提供的 UART 邏輯電源電壓是 1.8V，所以還要找支援 1.8V 的 USB-UART 轉接介面。
現在已經確定能夠在原裝的 Android 系統、從 serial console 獲取非常早期（從 S1 BOOT 開始）的開機時資料，接著要再度刷成 postmarketOS 看看當初是卡死在什麼地方。
雖然已經是隔了兩代的舊產品，但是我因此勉強能負擔（除了 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 也不會太過猛烈。
除去雜訊之後，感覺音質中規中矩，當然不比高級音響，但是符合這個價位的表現，且防震能力不錯。