RFC 9512:application/yaml

看到「RFC 9512: YAML Media Type」這個,原來還沒有註冊 application/yaml 啊...

另外在 media type 的文件裡面,意外的給出了安全性的建議:

Code execution in deserializers should be disabled by default and only be enabled explicitly. In the latter case, the implementation should ensure (for example, via specific functions) that the code execution results in strictly bounded time/memory limits.

這邊用的是 should 不是 SHOULD,所以當一般的英文句子在讀,而非具有規範性的敘述。

但還是給了預設關閉 code execution 的建議...

1990 年代俄羅斯人用 VHS 帶 (錄影帶) 備份數位資料的方法:ArVid

Hacker News 上看到「ArVid: how Russians squeezed 4 hard drives into one VHS tape in the 90s」這篇,在 1990 年代俄羅斯人發明了用 VHS 帶 (錄影帶) 備份數位資料的方式,這個套件叫做 ArVid

方法是利用家裡已經有的 VHS 機 (錄影機),然後在 386 的電腦上接一張 ISA 介面的卡 (對比現在的電腦環境就是 PCI-e 介面卡),然後把 ISA 卡接到 VHS 機的 Video In (負責備份資料) 與 Video Out (負責取回資料),另外 ISA 卡還有一個紅外線 LED 發射的模組線可以接到 (貼到) VHS 機器的接收處,這樣可以讓 ISA 卡透過「遙控器」的協定控制 VHS 播放器。

這個點子用的媒介其實類似於磁帶機,只是 ArVid 為了使用現成的 VHS 機,多了一個轉換成影像的步驟。

這邊 ArVid 加上了 Hamming code,提供之後讀取時,發現錯誤以及修正的能力。

三個小時的 VHS 帶可以存 2GB 的資料,這個空間大小的感覺拉一下「History of hard disk drives」這頁的資訊,可以感覺一下 1990 年代前期時這樣的東西大概是什麼感覺:

1990 – IBM 0681 "Redwing" – 857 megabytes, twelve 5.25-inch disks. First HDD with PRML Technology (Digital Read Channel with 'partial-response maximum-likelihood' algorithm).

1991 – Areal Technology MD-2060 – 60 megabytes, one 2.5-inch disk platter. First commercial hard drive with platters made from glass.

1991 – IBM 0663 "Corsair" – 1,004 megabytes, eight 3.5-inch disks; first HDD using magnetoresistive heads

1991 – Intégral Peripherals 1820 "Mustang" – 21.4 megabytes, one 1.8-inch disk, first 1.8-inch HDD

1992 – HP Kittyhawk – 20 MB, first 1.3-inch hard-disk drive

是個很有趣的產品啊...

讓 git blame 可以忽略掉某些 restyle/reformat 的 commit

在 X (Twitter) 上看到這則推,提到了可以讓 git blame 自動忽略掉某些 restyle 或是 reformat 的 commit:

查了一下是在 2019 年八月出的 2.23.0 引入的,從 Documentation/RelNotes/2.23.0.txt 可以看到說明:

 * "git blame" learned to "ignore" commits in the history, whose
   effects (as well as their presence) get ignored.

除了可以在專案內單獨設定外,也可以在 ~/.gitconfig 內設定:

[blame]
    ignoreRevsFile = .git-blame-ignore-revs

我是拿 rss-bridge 裡的 bridges/ARDMediathekBridge.php 測試,可以看到這個檔案最後的修改是「Reformat codebase v4」這包,也就是被放進 ignore 清單的 commit。

這個 commit 中,對 ARDMediathekBridge.php 這個檔案的 diff 則可以在「這裡」看到。

從 diff log 可以看到幾乎是所有的縮排都被改變了,但 GitHub 上面的 Blame 資訊,以及拉下來後用 git blame 或是 tig blame 可以注意到大多數有意義的地方都有被找出來「還原」,只有很簡單的內容沒有被辨識出來 (像是整行只有 /* 或是 { 之類的地方)。

看起來還是蠻有用的,先丟進 dotfiles 裡面了...

GitHub 新版 Code Search 後面砍掉重練的過程

Hacker News 上看到「Lessons from building GitHub code search (youtube.com)」這篇在講 GitHub 的 Code Search (今年九月在 Strange Loop 上的演講),同時演講者 Luke Francl (帳號是 100k) 也有在 Hacker News 上留言回答一些問題:

影片裡面有不少資訊,挑我自己覺得有趣的地方整理一下。(不是依照影片的順序)

首先是現成的 search engine (Elasticsearch) 會濾掉太多資訊,其中一種例子就是在程式語言中,各種 token 像是 <= 以及 > 這些,都算是有用的資訊。

另外一方面是 Elasticsearch 的架構下沒有辦法利用 fork 的性質 (以及 Git 的 branch 性質),所以在處理 fork 類的 repository 會造成大量重複的資料,但 fork 的資料會有 99% 以上是與原來的 repository 相同。

舊的系統有 312 servers,包括了 24960 cores 與 20TB RAM,直接平均下來,每一台機器是 80 cores 與 65GB RAM,而跑一次 reindex 會需要幾個月的時間。

新的系統則降到了 130 servers,包括了 8320 cores,但記憶體加到了 65TB RAM,直接平均下來,每一台機器是 64 cores 與 512GB RAM,後面有列出來是 Azure 的 L64s v3,剛好就是 64 cores 與 512GB RAM,然後帶有 640GB temp disk 與 8*1.92TB 的 NVMe disk。

另外有提到這套新的系統雖然比較小 (除了記憶體),但卻是 3 clusters,這也剛好解釋記憶體變成原來三倍的原因。

而更重要的是,因為有多個系統,所以他們可以在上面對 production 等級資料量進行測試,而且不用害怕炸掉東西。

而且新的系統從零 rebuild 一次只需要幾天,不像之前需要好幾個月。這些改變使得 engineer 更容易進行個重嘗試與改善,而不用把精神花在要怎麼維持相容性。

回到 CPU 數量的下降,這邊沒有直接提到原因,但演講裡有提到有不少東西改用 Rust 寫,等於是從 JVM 換到原生程式碼,對於會有大量時間花在 CPU 運算的服務來說是個明顯的加分。

中間有兩個提到演算法的事情也蠻有趣的。

第一個是在 Delta compression 的地方,把 fork 後的差異當作是 delta,要最小化整個 fork tree 的成本,剛好把這個東西轉換成圖論的問題,就可以套用 Minimum spanning tree 這個經典的演算法,而且 MST 太經典,有很多變形也都有人研究過,有限成的演算法可以用。

另外一個提到的是 Alexander Neubeck,從 LinkedIn 上的資料可以看到他在 Google 的時候就是負責 Code Search,後來到 GitHub 看起來剛好加入對應的團隊,他開發了一個新的資料結構 Geometrics XOR filter 來解決 Delta compression 遇到的問題。

在 Hacekr News 上的討論可以看到有人抱怨還是缺了重要的功能,不過這畢竟是砍掉重練開始搞,而且是配合 Git 與 GitHub 的特性設計的,可以預期會缺東西,但就像演講裡提到的,新的架構可以讓整個團隊更快的迭代進行各種嘗試,後續就比較會是官方要取捨實作哪些功能了...

AMD Zen 3 與 Zen 4 上 FSRM (Fast Short REP MOV) 的效能問題

前幾天 Hacker News 上討論到的一篇:「Rust std fs slower than Python? No, it's hardware (xuanwo.io)」,原文則是在「Rust std fs slower than Python!? No, it's hardware!」。

原因是作者收到回報,提到一段 Rust 寫的 code (在文章裡面的 read_file_with_opendal(),透過 OpenDAL 去讀) 比 Python 的 code 還慢 (在文章裡面的 read_file_with_normal(),直接用 Python 的 open() 開然後讀取)。

先講最後發現問題是 Zen 3 (桌機版 5 系列的 CPU) 與 Zen 4 (桌機版 7 系列的 CPU) 這兩個架構上 REP MOV 系列的指令在某些情境下 (與 offset 有關) 有效能上的問題。

FSRM 類的指令被用在 memcpy()memmove() 類的地方,算是很常見備用到的功能,這次追蹤的問題發現在 glibc 裡面用到導致效能異常。

另外也可以查到在 Linux kernel 裡面也有用到:「Linux 5.6 To Make Use Of Intel Ice Lake's Fast Short REP MOV For Faster memmove()」,所以後續應該也會有些改善的討論...

Ubuntu 這邊的 issue ticket 開在「Terrible memcpy performance on Zen 3 when using rep movsb」這,上游的 glibc 也有對應的追蹤:「30995 – Zen 4: sub-optimal memcpy on very large copies」。

從作者私下得知的消息,因為 patch space 的大小限制,AMD 可能無法提供 CPU microcode 上的 patch,直接解決問題:

However, unverified sources suggest that a fix via amd-ucode is unlikely (at least for Zen 3) due to limited patch space. If you have more information on this matter, please reach out to me.

所以目前比較可行的作法是在 glibc 裡面使用到 FSRM 的地方針對 Zen 3 與 Zen 4 放 workaround,回到原來沒有 FSRM 的方式處理:

Our only hope is to address this issue in glibc by disabling FSRM as necessary. Progress has been made on the glibc front: x86: Improve ERMS usage on Zen3. Stay tuned for updates.

另外在追蹤問題的過程遇到不同的情境,得拿出不同的 profiling 工具出來用,所以也還蠻值得看過一次有個印象:

一開始的 timeit 算是 Python 裡面簡單的 benchmark library:

接著的比較是用 command line 的工具 hyperfine 產生出來的 (給兩個 command 讓他跑),查了一下發現在 Ubuntu 官方的 apt repository 裡面有包進去 (22.04+):

再來是用 strace 追問題,這個算是經典工具了,可以拿來看 syscall 被呼叫的時間點:

到後面出現了 perf 可以拿來看更底層的資訊,像是 CPU 內 cache 的情況:

接續提到的「hotspot ASM」應該也還是 perf 輸出的格式,不過不是那麼確定... 在「perf Examples」這邊可以看到 function 的分析:

而文章裡的則是可以看到已經到 assembly 層級了:

差不多就這些...

Firefox 宣布從 Mercurial 換到 Git

Firefox 宣佈從 Mercurial 換到 Git:「Firefox Development Is Moving From Mercurial To Git」。

目前是 Mercurial 與 Git 都支援,理由是不想要維持兩套:

For a long time Firefox Desktop development has supported both Mercurial and
Git users. This dual SCM requirement places a significant burden on teams which
are already stretched thin in parts. We have made the decision to move Firefox
development to Git.

不過不知道決策的過程到底是怎麼產生的,算是 Mozilla 的老問題了...

OpenTF 開張

前陣子有提到因為 HashiCorp 沒有正面回應 (如預期的) 授權的爭議,所以決定將最後一個 open source 版本的 Terraform 給 fork 出來:「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」。

剛剛在 Hacker News 上看到「OpenTF repository is now public (github.com/opentffoundation)」這個,OpenTF 正式開張了。

瞄了一下 issues,初期還有蠻多雜事得處理的,但跨出第一步了,可以看看社群的能量到底有沒有超過 HashiCorp 自家的能量...

Rocky Linux 提出兩個方法取得 RHEL 的 source code

在「AlmaLinux 與 Rocky Linux 看起來都暫時無解」這邊提到了檯面上目前沒有好方法穩定取得 source code 後,Rocky Linux 提出了兩個方法,在不需要同意 RHEL 的條款下取得 RHEL 的 source code:「Keeping Open Source Open」。

中間還有一些小插曲可以提一下,在社群不少抗議聲後,IBM & Red Hat 的 VP 出來直接說他們認為 RHEL rebuild 沒有任何價值,而且是故意讓 rebuilder 更難實作 RHEL rebuild:「Red Hat’s commitment to open source: A response to the git.centos.org changes」。

Ultimately, we do not find value in a RHEL rebuild and we are not under any obligation to make things easier for rebuilders; this is our call to make.

回到 Rocky Linux 的文章,他們提出來的兩個方法都是基於 GPL 的重要性質:如果你可以合法拿到 binary,那麼散佈者就有義務要提供 source code。

第一個方法是透過 RHEL 目前公開提供的 container image:

One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.

另外一種方式是透過雲端服務的 cloud instance 跑 RHEL:

Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically.

這兩個方法都不需要同意 RHEL 目前在網站上的 TOS 與 EULA,而且短時間內應該不好防堵:前者要關掉的話,應該有一堆既有 RHEL 客戶在用會直接抱怨,真的要硬幹的話得給這些客戶時間從 public repository 轉移到要認證的 repository 上;而後者要堵的話,除非 IBM & Red Hat 決定直接不做雲端生意?

看起來 Rocky Linux 與 AlmaLinux 用這套方法可以撐一陣子,直到 IBM & Red Hat 想出新方法來搞?

AlmaLinux 與 Rocky Linux 看起來都暫時無解

昨天提到的「IBM 決定停止公開發布 RHEL 的 source code」有了另外一邊的說明了:

如同 AlmaLinux 所說的,重新散佈程式碼是受限的:

Unfortunately the way we understand it today, Red Hat’s user interface agreements indicate that re-publishing sources acquired through the customer portal would be a violation of those agreements.

所以目前 AlmaLinux 的意思是沒有什麼好解法,而 Rocky Linux 的公告文章只有幹話,沒有實質內容。

但我猜既有的客戶裡面有不受這個條款影響的族群,像是直接跟 IBM 談授權合約的公司,有可能會有排除單方面修改授權的條款,這個應該會是目前 RHEL 8/9 的破口,但後續再釋出的版本應該會被 IBM 的法務給補上?

IBM 決定停止公開發布 RHEL 的 source code

Hacker News 首頁上看到的新聞,IBM 決定停止公開發布 RHEL 的 source code:「Red Hat cutting back RHEL source availability」,原始的文章在「Furthering the evolution of CentOS Stream」這邊。

可以猜測這與 Rocky LinuxAlmaLinux 有關。

有購買 RHEL 的人 (取得 binary 的人) 可以在 Red Hat Customer Portal 上取得 source code,這部份應該是遵守 GPL 的關係。

但不確定後續 Rocky Linux 與 AlmaLinux 會怎麼處理,看了看 GPLv2 裡面的條文,不是很確定是否可以限制散佈 source code 的行為...