2012 年在 Google 時強制使用統一標準的 BUILD 檔案

Hacker News 上看到「Reformatting 100k Files at Google in 2011 (le-brun.eu)」這篇,原文在「The Story of Reformatting 100k Files at Google in 2012」這邊。

這篇除了作者寫的東西以外,Russ Cox 也在 Hacker News 上面分享了一些當時的背景。

故事是 2012 年的時候,作者 Laurent Le Brun (LinkedIn) 在德國,剛加入 Google 沒多久,負責處理 Google 內部的編譯工具 Blaze (外部稱 Bazel):

Back in September 2012, I was a junior engineer at Google, working on Bazel (Google’s build tool, also known internally as Blaze).

然後他與他的 team lead 收到美國團隊兩位工程師的會議邀請:

One day, a mysterious calendar invite landed in my inbox. It was sent by two engineers in the US, and I was invited along with my team lead.

然後這兩位是 Rob Pike 以及 Russ Cox:

I quickly recognized the names: Rob Pike and Russ Cox. Though I hadn't worked with them, I knew them by reputation: Russ Cox because I enjoyed reading his blog posts, and Rob Pike because, well… he’s famous.

作者這邊也懶得介紹 Rob Pike 了,畢竟是當年 Bell LabsPlan 9 的頭頭,然後又是 UTF-8 的發明人,後來在 Google 裡面也是 Go (程式語言) 的頭頭... 順便一提 Go 的吉祥物是他老婆畫的。

他們兩個人希望把全公司所有的 BUILD 檔案格式統一:

During the meeting, Rob and Russ shared their ambitious plan: to reformat every single Bazel BUILD file in Google’s codebase and enforce this formatting with a presubmit script.

中間有提到一些工程上的進行方式,但對我來說比較重要的是這幾個,首先是 Russ Cox 提到他在 Go 的團隊裡面學到的,(在大公司裡面) 不要讓工程師浪費時間在 formatting 之類的問題:

The formatting issue is a problem that should not exist and that we care enough about to spend our own engineering time eliminating it. I understand that it does not seem a priori that automated formatting would make a significant difference. I didn't truly understand it myself until we eliminated it from the Go code review and code editing processes. Hopefully in six months or a year, when everything is converted and we look back at this, the benefits will be clearer in retrospect.

另外在 update 的地方作者也提到了當時決定一次到位,把所有的 BUILD 檔案都修正完,而不是讓後續的人在更新時才強制要求,這樣可以避免後面的人接手的時候產生大量的 diff 而導致 review 困難:

Why not enable the new formatter without updating all the files? This would lead to long diffs whenever someone modifies a file, making the change hard to review. The cost would be spread over all the engineers in the company.

讓 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 裡面了...

arXiv 提供 HTML 版本介面 (beta 版)

Hacker News 上看到「ArXiv now offers papers in HTML format (arxiv.org)」這則,arXiv 推出了 beta 版的 HTML 介面:「Accessibility update: arXiv now offers papers in HTML format」。

不是每一篇都有上,需要是最近用 TeX 類格式上傳的才會轉:

We are happy to announce that as of Monday, December 18th, arXiv is now generating an HTML formatted version of all papers submitted in TeX/LaTeX (as long as papers were submitted on or after December 1st, 2023 and HTML conversion is successful – more on this below).

所以我先找了二十年前 Poincaré conjecture (龐加萊猜想) 的三篇論文,就沒有 HTML 版本:「The entropy formula for the Ricci flow and its geometric applications」、「Ricci flow with surgery on three-manifolds」、「Finite extinction time for the solutions to the Ricci flow on certain three-manifolds」。

Hacker News 的 comment 裡面有人給了有 HTML 版本的論文:「The detectability of single spinless stellar-mass black holes through gravitational lensing of gravitational waves with advanced LIGO」,以 render 的效果看起來還不錯?

另外這個站目前看起來沒有在 Fastly 上:

;; ANSWER SECTION:
browse.arxiv.org.       300     IN      A       34.160.61.147

應該等成熟進 GA 時會把所有 TeX 檔案都轉出來?

最近 AV1 的支援度

HN 上「AV1 video codec gains broader hardware support (fullystacked.net)」這篇在說 AV1 的支援度變得更好了,原文不長,在「The AV1 video codec gains broader hardware support」這邊。

Can I Use 上的 AV1 video format 可以看的比較清楚:

不過在瀏覽器上離直接取代掉其他的 video codec 還早,但算是個起頭,至少 iPhone 15 Pro 與 iPhone 15 Pro Max 上的 Safari 支援了,接下來就是看桌機的 Edge 什麼時候才又想到要把 AV1 開回來:

Edge has stopped supporting AV1 completely at some point prior to version 116 (additional information required).

OpenSSH 與 Dropbear 對 Ed25519 的支援

查了一下這兩個 server 端的軟體支援 Ed25519 的時間點。

OpenSSH 是在 2014/01/30 的 6.5 就支援了:

* ssh(1), sshd(8): Add support for Ed25519 as a public key type. Ed25519 is a elliptic curve signature scheme that offers better security than ECDSA and DSA and good performance. It may be used for both user and host keys.

算是相當久以前就支援了。對應到第一個支援的 Debian 版本是 Jessie 使用的 OpenSSH 6.7:「sshd(8) — openssh-server — Debian jessie — Debian Manpages」;第一個支援的 Ubuntu (LTS) 版本是 Trusty (14.04) 用的 OpenSSH 6.6:「openssh source package in Trusty」。

Dropbear 這邊就晚不少,在 2020/06/15 的 2020.79 版本才支援:

- Support ed25519 hostkeys and authorized_keys, many thanks to Vladislav Grishenko. This also replaces curve25519 with a TweetNaCl implementation that reduces code size.

所以對應到第一個支援的 Debian 版本是 Bullseye 的 2020.81:「Debian -- Details of package dropbear in bullseye」;第一個支援 Ubuntu (LTS) 的版本是 Jammy (22.04) 的 2020.81:「Ubuntu – Details of package dropbear in jammy」。

這樣看起來如果就是想要用 Ed25519 的話,變成 server 端的軟體得配合:預設裝的 sshd 應該都是 OpenSSH,如果想要換 Dropbear 的話要看 distribution 內給的版本夠不夠新,或是透過 PPA 之類的方法裝新版。

但大多數採用 BusyBox 的機器應該沒有採用新版 Dropbear (像是 AP 刷機),這邊還是得使用其他 key format,如果要避開 NIST 有介入的格式,就還是得用 ssh-rsa 了。

YAML 常見的問題

Hacker News Daily 上看到「The yaml document from hell」這篇在抱怨 YAML 的問題,而 Hacker News 上對應的討論在「The Yaml document from hell (ruudvanasseldonk.com)」這邊。

翻了一下我之前也有提到好幾次不同來源的抱怨:「YAML 的地雷 (2014)」、「YAML 的痛點 (2019)」、「YAML 的問題 (挪威問題) (2021)」。

這篇提到的東西還是類似之前提到的,但整理的蠻不錯的?他給了一個看起來蠻正常的 YAML,然後裡面全部都是地雷,你可以看他的說明知道是什麼問題。

不過他提出來的問題都是可以加上 double quote 來避開,但把這個方式當作 common practice 用 YAML 會變得很痛苦。

不過市場上還沒有能取代的東西,只能先繼續邊用邊罵了,看了一下 Hacker News 上的留言,簡單一點的東西 (只是要放幾個值的) 大家都覺得 INI 還可以拿來用用...

fp32、fp16 與 bf16

nanoGPT 這個專案下面看到 bf16 這個浮點格式:(這段在新版的 README.md 被改寫了)

Currently fp16 is much faster than bf16. Potentially revert back to using fp16 and re-introduce the gradient scaler?

翻了一下 bf16,是由 Google 的團隊所提出來的想法,主打是與 fp32 相同的表示範圍,但是犧牲精度,這樣一來既有使用 fp32 的程式很有機會可以直接換成 bf16 降低計算量 & 提昇效率 (也就是 drop-in replacement):

然後同一頁也看到各家自己推出不同的格式,這邊看起來比較像是市場競爭的關係...

Python 的 Black

Hacker News 上看到 Black 這個幫你處理 Python 程式碼的工具:「Black, the uncompromising Python code formatter, is stable (pypi.org)」。

Black is the uncompromising Python code formatter. By using it, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

然後從 Hacker News 上討論的情況看起來大家都覺得很不錯?好像可以看看能不能拿來用...

另外一個在討論的時候看到學到的東西,是 git blame --ignore-revs-file 這個功能,可以在 git blame 時濾掉某些 commit,剛好拿來過濾 reformatting commit:

Ignore revisions listed in file, which must be in the same format as an fsck.skipList. This option may be repeated, and these files will be processed after any files specified with the blame.ignoreRevsFile config option. An empty file name, "", will clear the list of revs from previously processed files.

QOI 圖片無損壓縮演算法

Hacker News Daily 上看到「Lossless Image Compression in O(n) Time」這篇,作者丟出了一個圖片的無損壓縮演算法,壓縮與解壓縮的速度超快,但壓縮率又不輸 PNG 太多,在 Hacker News 上的討論也可以看一下:「QOI: Lossless Image Compression in O(n) Time (phoboslab.org)」。

裡面有提到在遊戲產業常用到的 stb_image.h

Yes, stb_image saved us all from the pains of dealing with libpng and is therefore used in countless games and apps. A while ago I aimed to do the same for video with pl_mpeg, with some success.

作者的簡介也可以看到他的主業也在遊戲這塊:

My name is Dominic Szablewski. I build games, experiment with JavaScript and occasionally tinker with low-level C.

圖片的無損壓縮與解壓縮算是遊戲創作者蠻常用到的功能,所以他想要看看這塊有沒有機會有更好的工具,於是他就用了四個很簡單的演算法幹完了 QOI (然後發現效果很讚):

  • A run of the previous pixel
  • An index into a previously seen pixel
  • The difference to the previous pixel
  • Full rgba values

其實從 Hacker News 的討論也可以看到這組演算法也常被拿出來在現代的壓縮演算法使用,所以雖然作者自稱不是 compression guy,但他用的演算法其實蠻專業的...

然後挑 single thread 主要是可以避免 threading 的複雜度以及 overhead,在「QOI Benchmark Results」這頁可以看到,無論是什麼類型的檔案,壓縮與解壓縮的速度都相當漂亮,而且壓縮率又沒有差 libpng 太多。

而且作者自己有提到,還沒用到 SIMD 指令集加速,這樣猜測應該還有不少空間...

在 command line 下生出全灰的圖片

因為需要一張 1920x1080 全灰色的圖片,翻了一下 DuckDuckGo 找到這篇:「Linux create Image pixel by pixel in command line」。

裡面抓重點,主要的想法是 PPM 格式 (可以參考「Netpbm」這個條目),然後找到「PPM Format Specification」這份文件。

主要就是用 P3 模式下去產生檔案:

repeat 2073600 echo '127 127 127' >> grey.ppm

然後開頭的地方修一下,加上 P3、長寬資訊以及最大的值:

P3
1920 1080
255

接著就用 ImageMagick 轉檔:

convert grey.ppm grey.png

然後用 viewer 看一下,確認沒問題就收工了...