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，只能先繼續把票追起來。

Tomato64 專案：x86-64 版本的 Tomato

看到 x86-64 版本的 FreshTomato：「Tomato64: A port of Tomato Firmware to x86_64 (tomato64.org)」，專案官網在 Tomato64 這邊。

Hardware (Router) Compatibility 這邊可以看到原專案主要支援的是 ARM 與 MIPS 平台，沒有 x86 系列平台的影子。

x86 的多有線網路 + 無線網路機器算是蠻好取得的 (甚至可以自己組裝)，先前我應該會裝 pfSense，現在多了一個選擇可以用，不過 feature list 裡面沒看到 IPsec，看起來是原版就沒支援，得自己在 cli 裝套件跑起來設定？

本來在想有沒有機會跑在 Amazon EC2...

HTTP/3 + QUIC 的效率問題

前天看到討論蠻熱烈問題，提到了 HTTP/3 + UDP-based 的 QUIC 的效率比起 HTTP/2 + TCP-based 的 TLS 慢很多的問題：「QUIC is not quick enough over fast internet (acm.org)」，原文在「QUIC is not Quick Enough over Fast Internet」，如果要看 PDF 的話可以看預印本上的「QUIC is not Quick Enough over Fast Internet」。

之所以會有這麼多討論，是因為這篇文章說 HTTP/3 + QUIC 得到的效果與當初宣稱的完全相反，在所有的測試下都比 HTTP/2 + TLS 慢很多。

包括了在高速的網路下差了 45.2% (而且是網路愈快差距愈大)：

We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover, the performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases.

以及在輕量的使用下也是 HTTP/2 + TLS 比較快，這邊提到包括各種桌機與手機環境，以及各種瀏覽器：

We observe this issue on lightweight data transfer clients and major web browsers (Chrome, Edge, Firefox, Opera), on different hosts (desktop, mobile), and over diverse networks (wired broadband, cellular).

讀完 PDF 的分析後，看起來是因為 TCP 大家花了很多精力在上面最佳化 50 年了，這邊累積的資產不只是軟體層級上面的最佳化，OS 與硬體上面也是有很多 offload 幫助。

而自己幹輪子的結果就是軟體層也還缺很多東西，硬體層也不支援新的協定...

SpaceHey 的百萬用戶

在「1M Users (spacehey.com)」這邊看到的，原文是「1,000,000」。

SpaceHey 在 2020 年的時候由 18 歲的 Anton Röhm 建立的，從風格就可以看出來很 2000 年左右的風格？

技術上用的是純 PHP + MySQL + HTML：

不過雖然是用 2000 年就有的技術衝到 1M users，但技術上各方面的成熟度都完全不一樣了，現在的 1M users 應該還是暴力解可以處理的範圍，不需要弄花俏的 sharding XD

但看到有人用古董做出 1M users 的網站還是覺得很厲害 XD

讓 Flatpak 裡面的應用程式可以吃到系統的字型

先前在「測試 Zen Browser」這邊提到 Zen，但遇到中文字型用了文泉驛正黑而沒有用 Noto Sans CJK TC 的問題，當時先一直放著，後來想到應該是 Flatpak 的 sandbox 造成的，用關鍵字找了一下資料可以在 GitHub 上看到這則說明：「[feature] Expose xdg-config/fontconfig to sandbox by default #3947」。

透過 cli 或是 Flatseal 在 Filesystem 的部分將 xdg-config/fontconfig:ro 設進去就可以了。

其中這邊的 magic word xdg-config 是出自「Sandbox Permissions」這邊，裡面也有提到 :ro 的部分，所以上面提到的 xdg-config/fontconfig:ro 就會是 ~/.config/fontconfig 的 readonly 權限了。

接著就可以在 ~/.config/fontconfig 裡面設定自己要的字型了。

Problem Details for HTTP APIs (RFC 7807 變成 RFC 9457)

之前寫過「RFC 定義的 application/problem+json (或是 xml)」，最近在找資料發現 2016 年的 RFC 7807 被 2023 年的 RFC 9457 取代了，兩份的標題都是「Problem Details for HTTP APIs」。

在「Appendix D. Changes from RFC 7807」這邊有提到做了什麼修改，看起來有三點：

Section 4.2 introduces a registry of common problem type URIs
Section 3 clarifies how multiple problems should be treated
Section 3.1.1 provides guidance for using type URIs that cannot be dereferenced

看起來大骨架沒有變，主要是補充了一些不足而已...

nginx 專案搬到 GitHub 上

在「Nginx has moved to GitHub (nginx.org)」看到的，原連結是「[nginx-announce] NGINX has moved to Github!」。

這次搬移也順便將本來是 Mercurial 的專案換到 Git 上了...

Hacker News 有不少人在討論現在 nginx 目前的情況，像是之前有提到分家的事情：「nginx 分家：freenginx」。

不過基本功能都算成熟很久了，算是還好？

CSS 的 all 屬性

查資料注意到 CSS 的 all 屬性可以用來清除網站上的設定 (通常需要加上邪惡的 !important)，剛好搭配 uBlock Origin 的 :style，可以很方便的用自訂規則處理掉：

www.example.com##div.foo:style(all: initial !important;)

當然這也可以用在 UserCSS 上面。

從 Can I Use? 這邊看起來兩個陣營大概都是 2014 年就支援這個屬性了，所以自己用的話不用太在意相容性的問題：「CSS all property」。

RAID6 的 Erasure code 實作

Daily Hacker News 上看到的紋章，「Erasure Coding for Distributed Systems」這篇討論了 Erasure code。

以前在學校裡面學 coding theory 的時候有學到一些經典的演算法，尤其是一定會教到 Reed-Solomon error correction 這個演算法，不過實務上 Reed-Solomon 因為用到 finite field 運算 (又稱 Galois field，所以簡寫常用 GF)，所以效率並不算好，在 RAID 系統上面除非 controller 的 CPU 或是晶片對 GF 運算加速，不然大多都會用替代算法。

For the special cases of 1-3 parity chunks (m \in {1,2,3}), there are algorithms not derived from Reed-Solomon and which use only XORs:

允許掛一顆的演算法就是 RAID 5，這邊用 XOR 就很容易導出來，並且分析證明。

開始有難度的是允許掛兩顆的演算法，也就是一般熟知的 RAID 6，在這篇文章裡面提到了好幾個演算法，不過有些有專利問題：

m=2 is also known as RAID-6, for which I would recommend Liberation codes[8][9] as nearly optimal with an implementation available as part of Jerasure, and HDP codes[10] and EVENODD[11] as notable but patented. If k+m+2 is prime, then X-Codes[12] are also optimal.

允許掛三顆的則是提到 STAR coding：

m=3 can be done via STAR coding

算是留個記錄好了，這些演算法又讓我想到先前剛進 Migo 的時候還學到 Raptor code，但使用場景不對反而遇到問題，又是另外一個故事了...

回到開頭的 Reed-Solomon，會印象很深還是因為當初在數學系的集合論學了 finite field 好幾年後，在資工系第一次看到居然可以用 finite field 解決這個問題...