幹壞事是進步最大的原動力
手上有個前端專案的開發環境是在 Linux container 上跑起來，有支援修改時 auto reload，我在 Linux Desktop 上面跑起來沒有問題，但在 MacBook (M 系列) 上開發就發現不會 auto reload，這樣改起來頗麻煩...
馬上有在猜是不是 inotify 的問題，先翻了一下資料，發現 inotify 在 Podman 上沒有被完整支援：「file changes not registered by inotifywait inside podman on Mac #19430」、「cannot receive inotify on shared directories when using AppleHV #22343」。
接下來把 Podman 換成 Docker，就發現解決了，看起來我遇到的應該就是 Podman 對 inotify 的支援度問題。
這樣開發上沒辦法用 Podman，只能先繼續把票追起來。
結果是在 Plurk 上面看到 https://www.plurk.com/p/3g8a60cuxm 這則消息，原公告在「[重要事項]工作站系統升級維護及 FreeBSD EOL 規劃」這邊。
與 Linux 相關的是 alumni 工作站從 FreeBSD 換 Debian：
alumni 工作站將由 Debian 系統取代。
現有的 alumni 工作站將於維護當天改名為 alumni1。
我們將提供三個月的遷移時間，alumni1 工作站將於三個月後停止服務。
而與 FreeBSD 有關的則是先縮減，然後三個月後停止服務：
將縮減至兩台工作站 bsd[1-2].cs.nycu.edu.tw
BSD 工作站將於三個月後停止服務。
雖然 alumni 主機只有偶而會連回去跑個 MTR 看各種 routing，但撤掉 FreeBSD 還是有點感傷啊。
不曉得現在 SA/NA 課程還有沒有在教 FreeBSD...
Hacker News 上看到 Android 在規劃 16KB Page Size 的消息：「Adding 16 kb page size to Android (googleblog.com)」，原文是「Adding 16 KB Page Size to Android」。
Android 目前主力是 4KB Page Size，但因為 ARM 有支援 16KB Page Size，所以測試後發現雖然會多用 9% 記憶體，但效能會增加不少：
Most CPUs today support a 4 KB page size and so the Android OS and applications have historically been built and optimized to run with a 4 KB page size. ARM CPUs support the larger 16 KB page size. When Android uses this larger page size, we observe an overall performance boost of 5-10% while using ~9% additional memory.
雖然說 overall performance 有提升，但在「Benefits and performance gains」這邊可以看到目前列出來的項目都是特定的行為 (像是 app 啟動，camera 啟動，或是開機時間)，這點可能要再看看其他的評測。
16KB Page Size 應該是個取捨，畢竟手機不像伺服器隨便就是上百 GB RAM 甚至到 TB RAM，跑一些吃記憶體的應用用 Huge Page 拉到 MB 等級的 Page Size 比較划算...
去年 Linux Kernel 決定將 LTS 從六年縮短為兩年 (參考先前寫到的「Linux Kernel 後續的 LTS 版本將縮短成兩年」)，而 Android 這邊決定後來的 LTS 版本將額外提供兩年支援，變成四年：「Google extends Linux kernel support to keep Android devices secure for longer」，引用的報導在「Google extends Linux kernel support to keep Android devices secure for longer」。
在 Android 的說明文件「Android common kernels」這邊有提到這個時間：
Beginning with kernel 6.6, the support lifetime for the stable kernels is 4 years.
應該是 Android 本身的 support policy 需要這個長度...
五月的時候有提過 NVIDIA 有計畫要使用 open-source license 的 Linux driver：「Nvidia 在 Linux 上安裝核心驅動程式時將建議使用開源版本」，現在則是正式公告了：「NVIDIA Transitions Fully Towards Open-Source GPU Kernel Modules」。
支援的 GPU 分成三塊，第一塊是只有 open-source 版本有支援，目前已經推出的產品應該是只有 GH200 是這個架構：
For cutting-edge platforms such as NVIDIA Grace Hopper or NVIDIA Blackwell, you must use the open-source GPU kernel modules. The proprietary drivers are unsupported on these platforms.
然後是 Turing 後的架構，以桌機顯卡來說的話是 2016 年出的 20 系列架構 (值得提一下的是，16 系列雖然看起來數字比較小，但是是 2019 年出的 Turing 架構，所以也支援)：
For newer GPUs from the Turing, Ampere, Ada Lovelace, or Hopper architectures, NVIDIA recommends switching to the open-source GPU kernel modules.
舊的系列則是不支援，以桌機來說就是 10 系列以及更舊的卡：
For older GPUs from the Maxwell, Pascal, or Volta architectures, the open-source GPU kernel modules are not compatible with your platform. Continue to use the NVIDIA proprietary driver.
再等一兩個版本再來換過去...
話說找資料發現維基百科上面用 Nvidia，但我找資料發現官方名稱是用 NVIDIA，翻了討論頁發現 2010 年就有人幹剿過了 (在 Naming Conventions 這段)，看起來是不會改？
在「NUMA Emulation speeds up Pi 5 (and other improvements)」這邊看到的，最近 Linux kernel 有些新的 patch 對 Raspberry Pi 的效率有不少提升。
其中 NUMA Emulation 這包對於 Raspberry Pi 5 的效能提升頗多：
[I]t can bring a significant performance uplift on Raspberry Pi 5.
照他的說法，Geekbench 6 的提升部分，單核 6% 多核 18%：
In more conrete numbers, testing with Geekbench 6 shows that splitting into four emulated NUMA nodes can uplift the single core score of the benchmark by around 6%, and the multi-core by around 18%.
Jeff Geerling 測試的結果則是 6% & 12%，沒有宣稱那麼多，但仍然是不小的提升。
話說我還在想要不要弄一台 Raspberry Pi 5，目前手上有幾台 1B、一台 3B+ 以及一台 4，除了跑 SmokePing 以外還有什麼值得跑的...
在「Capturing Linux SSL/TLS plaintext without a CA certificate using eBPF (github.com/gojue)」這邊看到的工具，可以透過 eBPF 直接攔 TLS 連線的明文，專案在 gojue/ecapture 這邊可以看到。
除了支援 OpenSSL，還支援了 GnuTLS 與 NSS，看起來常見的 library 都有支援。
算是 reverse engineering 的工具，看起來會適合用在應用程式有 pinning 的情況下 (像是 CA pinning，或是 certificate pinning)，有機會省下改 binary 的麻煩。
在「Welcome to Ladybird, a truly independent web browser (ladybird.org)」這邊看到的，指到官網 Ladybird 上。
最主要的資訊應該是這個日期，目前計畫是 2026 夏天在 Linux 與 macOS 上推出 alpha 版：
We are targeting Summer 2026 for a first Alpha version on Linux and macOS. This will be aimed at developers and early adopters.
也就是大約再兩年，看起來得花不少時間開發... 畢竟是要完全獨立開發不使用現有瀏覽器的 code。
結論：用 Perl。
寫 shell script 的時候遇到的問題，在 Linux 上面使用 sed 換檔案裡面的字串，但不想要產生 backup file 的方式是：
sed -i -e 's/foo/bar/' example.txt
但在 macOS 內建的 sed 則是：
sed -i '' -e 's/foo/bar/' example.txt
也就是說前者 GNU sed 是處理 $1 (argv[1]，anyway) 後面貼著的參數，而後者 macOS 的則是吃 $2 (argv[2]) 的參數。
在 Stack Overflow 上的「sed in-place flag that works both on Mac (BSD) and Linux」這邊有討論，看起來 sed 上沒有通解。
翻了 The Open Group 上的說明，sed 應該是定義在 POSIX 裡面，而從文件裡面沒有提到 backup file 可以知道這是各家自己實作的功能：「sed」。
所以一種解法是用 detection 的方式針對不同的 sed 給不同的指令；而另外一種解法是找其他工具。後者考慮到普及性，用 Perl 應該會是比較好的方式，目前不是 minimal 類的系統應該都還有 Perl 可以用：
perl -pi -e 's/foo/bar/' example.txt
但這樣跑在 CI 裡面的時候就得小心一點了，如果選到 minimal image 的話就會中獎... (煩躁？)
在「Libtree: Ldd as a tree saying why a library is found or not (github.com/haampie)」這邊看到的，本來看到名字以為是與樹狀資料結構有關的 library，結果實際看了發現這邊的 libtree 指的是將執行檔裡面使用到的 dependency (library) 展成樹狀：
比起 ldd 的輸出多了更多資訊，這個在想辦法解決 library 問題時比 ldd 好用不少。