Podman 下的 inotify 問題

手上有個前端專案的開發環境是在 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,只能先繼續把票追起來。

陽交大資工 (原交大資工) 要退役 FreeBSD 伺服器了

結果是在 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...

Android 規劃 16KB Page Size

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 比較划算...

OpenBSD 程式碼的忒修斯之船

在「We have reached OpenBSD of Theseus (marc.info)」這邊看到的有趣主題,連結到的是 OpenBSD 的 commit log:「CVS: cvs.openbsd.org: src」。

The greek quiz is so obscure that it is ridiculous -- noone can play this. Replace it with a new quiz about galley (ship) parts. This commit changes the *LAST UNMODIFIED ORIGINAL FILE* (meaning revision 1.1.1.1) from the original import that created OpenBSD on Oct 18, 1995. With this commit, we have completed an amusing mission of replacing the final parts of the original OpenBSD.

We have reached OpenBSD of Theseus.

這邊提到的 Theseus 是指「忒修斯之船 (Ship of Theseus)」,引用中文維基百科的說明比較好理解:

如果忒修斯的船上的木頭逐漸被替換,直到所有的木頭都不是原來的木頭,那這艘船還是原來的那艘船嗎?

回到 OpenBSD 來說,這次的這個修改據說是最後一個沒有被動過的檔案,所以在改完以後才會說「We have reached OpenBSD of Theseus.」,是個有趣的里程碑。

Homebrew 上的降版與鎖版

標題是在找到「vim-indent-guides doesn't work on Neovim 0.10.x (on macOS)」這個問題時用到的方法,Homebrew 在新版不支援直接透過 command line 降版 (網路上可以找到不少 Homebrew 舊版的處理方法,但已經不能用了),就變得很麻煩...

這邊以 Neovim 為例子,可以找到對應的 formulae 在「neovim — Homebrew Formulae」這邊,裡面有 Formula code 的連結指到特定的 commit id 上,我這邊則是指到 master branch 上:「neovim.rb」。

接下來透過 History 頁面可以看到這個檔案被修改的記錄:「History for Formula/n/neovim.rb - Homebrew/homebrew-core」,可以看出來 commit 後會有機器人 BrewTestBot 編 binary package 然後更新文件內的 hash 資訊 (官方稱作 Bottles)。

接下來就是要挑一個版本點進去,我這邊舉例抓的是 0.9.5 的「neovim: update 0.9.5 bottle.」這個,然後從三個點的 icon 上點開,裡面的 View file 點下去後就會出現單一檔案的畫面,裡面有 Raw 可以點,就可以抓到像是 https://raw.githubusercontent.com/Homebrew/homebrew-core/63aa44faba5b5274a1a7579510cd5a570a2cca5f/Formula/n/neovim.rb 這樣的連結了。

這邊的檔案名稱不能換,但為了測試方便,我的方法是把不同 Neovim 版本的檔案都抓下來改檔名成 neovim-0.10.1.rbneovim-0.10.0.rb 以及 neovim-0.9.5.rb,後續再用 soft link 的方式 ln -fs neovim-0.10.1.rb neovim.rb 讓 Homebrew 讀到 neovim.rb 的檔案名稱,像是這樣:

wget -O neovim-0.9.5.rb https://github.com/Homebrew/homebrew-core/blob/63aa44faba5b5274a1a7579510cd5a570a2cca5f/Formula/n/neovim.rb
wget -O neovim-0.10.0.rb https://raw.githubusercontent.com/Homebrew/homebrew-core/5990ac73d16c4544d85fc67dad4405dda1e74fd6/Formula/n/neovim.rb
wget -O neovim-0.10.1.rb https://github.com/Homebrew/homebrew-core/blob/a75fe3a7ab97f97dc9999e7390184869be73227c/Formula/n/neovim.rb
ln -sf neovim-0.9.5.rb neovim.rb

Wget 或是 cURL 抓下來後就可以要 Homebrew 安裝了,在安裝前要記得先 uninstall 現有的版本:

brew uninstall neovim
brew install -s neovim.rb

以 Neovim 來說,跑完後用 nvim --version 就可以看有沒有裝到對的版本,其他軟體應該也會有對應的版本資訊可以看。

鎖定版本以及解除鎖定比較簡單,用 pinunpin 處理就可以了:

brew pin neovim
brew unpin neovim

看起來 Apple 是打算繼續蒐集 OCSP 資訊...

在「Apple memory holed its broken promise for an OCSP opt-out (lapcatsoftware.com)」這邊看到的,原文是「Apple memory holed its broken promise for an OCSP opt-out」。

Apple 的系統機制會在每次啟動應用程式的時候去 Apple 自家的 OCSP 伺服器確認這個應用程式是否被 Apple 註銷了:

When you launch an app, macOS connects to Apple's OCSP service to check whether the app's Developer ID code signing certificate has been revoked by Apple.

本來 Apple 有說要改善,但看起來吃書了...

這有明顯的 privacy 問題,所以我的作法是參考 Apple 自家的「Use Apple products on enterprise networks」這份官方資料,把裡面所有 ocsp 相關的 record 都設到 /etc/hosts 內,目前是:

127.0.0.1 ocsp.apple.com ocsp.digicert.cn ocsp.digicert.com ocsp.entrust.net ocsp2.apple.com

可以重開機確保生效,然後用 ping ocsp.apple.com (或是其他 domain) 看看是不是 127.0.0.1

Android 的 Linux Kernel 將會有四年的維護期

去年 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 正式推出開源版本的 Linux driver 了

五月的時候有提過 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 這段),看起來是不會改?

最近 Linux Kernel 對 Raspberry Pi 效率的提升

在「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 以外還有什麼值得跑的...

Linux 上的 GNU sed 與 macOS 內的 sed 的 in-place 差異

結論:用 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 的話就會中獎... (煩躁?)