Debian 的 64-bit time_t 計畫

在「Debian: 64-bit time_t transition in progress」這邊看到 Debian 的 mailing list 上的討論:「64-bit time_t transition in progress」,另外官方也有整理 wiki page:「64-bit time」。

因為技術上無法表示 2038/01/19 以後的時間,確定會 breaking ABI 將 time_t 從 32-bit 變成 64-bit,而現在要想辦法搞定 32-bit 平台上面可以處理這樣的改變:

The goal of this transition is to ensure that 32-bit architectures in trixie (whether they are currently release architectures, or out of archive, etc) will be capable of handling current and future timestamps referring to times beyond 2038.

離 2038/01/17 還有約 13 年多...

VirtualBox 的 KVM backend 版本

看到「VirtualBox KVM Public Release (cyberus-technology.de)」這邊的討論,原文是「VirtualBox KVM public release」,專案則是在 GitHub 上的 cyberus-technology/virtualbox-kvm 這邊。

這個算是解決了 VirtualBoxLinux 上常遇到的問題:當使用 VirtualBox 時無法同時使用 KVM,像是 qemu-kvm 這樣的工具。

不過看起來是直接大改 VirtualBox,而不是補一個 extension 或是 plugin 的感覺,雖然說明現有的 guest OS 可以直接套用。

沒有 pre-compiled binary,需要自己編,而且目前的版本得用 Ubuntu 22.04 內的 GCC 11 編譯,裝了新版的 GCC 12 會有狀況:

Newer GCC versions (>= 12) might cause build issues.

另外目前的主要測試的平台還是以 Intel 為主,AMD 這邊是「會動」但沒有詳細測過:

Currently, Intel x86_64 is the only supported host platform.
AMD will most likely work too but is considered experimental at the moment.

然後在比較新的 Intel 平台上,Linux kernel 有些東西要開機參數調:

Starting with Intel Tiger Lake (11th Gen Core processors) or newer, split lock detection must be turned off in the host system. This can be achieved using the Linux kernel command line parameter split_lock_detect=off or using the split_lock_mitigate sysctl.

看到編譯參數裡面的 --disable-hardening,hmmm... 先繼續放著看看?

systemd 的問題

Lobsters 的「systemd through the eyes of a musl distribution maintainer」這篇看到的,隔壁 Hacker News 的「Systemd through the eyes of a musl distribution maintainer (catfox.life)」也可以參考,原文在則是「systemd through the eyes of a musl distribution maintainer」這邊。

裡面提到的幾個痛點算是社群的共識了,像是負責 DNS 的 systemd-resolved,我之前有寫「Ubuntu 20.04 下用 resolvconf 取代 systemd-resolved (因為 PPPoE)」這個,回頭去用 resolvconf 支援度比 systemd-resolved 好很多。

另外一個社訊的共識是 systemd 多做了很多不屬於他的事情,像是跑去處理網路 (systemd-networkd),或是 NTP client (systemd-timedated),處理得很半吊子...

但偏偏市占率大的 distribution 都跳過去用 systemd,而 OpenRC 只有少數幾個 distribution 在用,佔有率差太多...

Gentoo 宣佈支援 binary package

Hacker News 上看到「Gentoo goes Binary (gentoo.org)」這篇,原文在「Gentoo goes Binary!」這。

Gentooportage 知名,這點在維基百科條目開頭就有提出來:

Gentoo Linux (pronounced /ˈdʒɛntuː/ JEN-too[3]) is a Linux distribution built using the Portage package management system. Unlike a binary software distribution, the source code is compiled locally according to the user's preferences and is often optimized for the specific type of computer.

這算是 Gentoo 的特色,不過即使 Gentoo 超愛 source package,也還是支援 binary package 安裝,但以前只提供重點套件,這包括了像是 Linux kernel 以及 gcc 這種套件,總是要有這些東西才能開始編軟體。

而這次公告宣佈要全面支援 binary package 算是個大轉變:

To speed up working with slow hardware and for overall convenience, we’re now also offering binary packages for download and direct installation!

目前 binary package 的主力會在 amd64 與 arm64 平台,然後提到這會對 mirror site 有額外的空間需求:

For most architectures, this is limited to the core system and weekly updates - not so for amd64 and arm64 however. There we’ve got a stunning >20 GByte of packages on our mirrors, from LibreOffice to KDE Plasma and from Gnome to Docker. Gentoo stable, updated daily.

從文末的圖也可以看到「the amount of binary package data in GByte for each architecture」得資訊:

想得到的客群大概是兩種,第一類是對於想用 Gentoo 看看的人來說會更好入手,尤其是手上是 Raspberry Pi 這些 CPU 不快的 SBC 會方便不少...

另外一種是不太在意效能,但是對某些 package 來說有高度客製化需求的人,會希望自己編這些 package 的人,透過 portage 自己調整。

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 層級了:

差不多就這些...

在 Linux 下將沒有安裝的字型指定替代物 (Consolas -> Inconsolata)

在看文件的時候發現 css fallback 的關係,被一路退到 Courier New,字有點太細... 然後發現 Consolas 沒有被指定替代字型 (通常會選 Inconsolata),依照「Font configuration」這邊的 alias 設定不會動,還是得用 match 去換。

要把 Consolas 換成 Inconsolata 的話,需要把設定加到 fontconfig 的設定裡面:(像是 ~/.config/fontconfig/fonts.conf,或是 /etc/fonts/conf.d/ 裡面放一個號碼大一點開頭的,像是 99-match.conf 之類的)

<match target="pattern">
        <test qual="any" name="family">
                <string>Consolas</string>
        </test>
        <edit name="family" mode="assign" binding="same">
                <string>Inconsolata</string>
        </edit>
</match>

瀏覽器因為有 cache 的關係,會需要重開生效。

另外一個有換的是 Menlo 換成 Bitstream Vera Sans Mono,換完後也好不少。

Bcachefs 進入 Linux Kernel 6.7 主線了

Bcachefs 是 Linux 下一個新的 filesystem (但也發展了好幾年),剛剛看到進入 Linux Kernel 6.7 的主線了:「Bcachefs Merged Into The Linux 6.7 Kernel」。

看起來沒搭上 6.6 的列車 (前幾天出的,2023/10/30),但以目前 Linux Kernel 的步調來看,6.7 應該是兩個月後就會釋出,Ubuntu 有機會在明年的 24.04 內建...

從官網列出來的功能可以知道,Bcachefs 實作了很多現代 filesystem 會發展的功能,像是 compression、encryption 以及 snapshots,另外底層也實作了 checksum 與 copy on write。

這樣看起來,Bcachefs 目前在 Linux 上主要的競爭對象應該會是 OpenZFS。真正的比較應該會等到 6.7 的 rc 版本就會有人下去測,到時候再看看,甚至看看有沒有機會取代 ext4 變成預設的 filesystem。

Linux Kernel 後續的 LTS 版本將縮短成兩年

在「Long-term support for Linux kernel to be cut as maintainence remains under strain」這邊看到 Linux Kernel 後續的 LTS 版本將縮短成兩年的消息:

Here's one major change coming down the road: Long-term support (LTS) for Linux kernels is being reduced from six to two years.

主要的原因是舊版用的人並不多:

Why? Simple, Corbet explained: "There's really no point to maintaining it for that long because people are not using them." I agree. While I'm sure someone out there is still running 4.14 in a production Linux system, there can't be many of them.

而目前的 LTS kernel 還是會走完本來計畫的時間,4.14、4.19、5.4 以及 5.10 從表上看都是六年,5.15 是五年,最新的 LTS 6.1 則是四年。

降到兩年的話,代表各家 Linux distribution 在 LTS kernel 跑完生命週期後就得自己維護安全性更新了,或是直接升級到另外一個 kernel 版本 (後者的方法風險高一點,不確定系統的相容性)。

看起來 5.10 與 6.1 會跑很久了,都到 2026 年十二月...

OpenTF (Terraform 的 fork) 改名為 OpenTofu

在「OpenTF 開張」這邊提到 Terraform 的 fork 叫做 OpenTF,現在改名為 OpenTofu:「New name for the OpenTF project #296」,同時也可以從官網看到正式加入 The Linux Foundation Projects

有幾個報導都有提到了:「Terraform fork gets renamed OpenTofu, and joins Linux Foundation」、「Terraform fork OpenTF renamed and relocated as OpenTofu」。

看了 Hacker News 上的討論,據說 cli 也會從 tf 換成 tofu...

ReiserFS 被標為 Obsolete

八月底的時候看到「ReiserFS Officially Declared "Obsolete"」這則新聞,這個有進到 Linux kernel 的是 Reiser3,不是後來有人接手但沒有進到 Linux kernel 裡的 Reiser4

在 5.18 的時候先標成 deprecated:「Linux 5.18 Moves Ahead With Deprecating ReiserFS」。

這次的 6.6 則是標成 Obsolete,逐步從 Linux kernel 裡面拔除:

As part of updates to the older file-system drivers for Linux 6.6, the ReiserFS file-system is no longer marked as "Supported" but is officially treated as "Obsolete" within the Linux kernel.

目前各大 Linux 套件的預設檔案系統應該都是 ext4,另外有些特殊情境下 XFS 也蠻好用的 (像是資料庫),對於追求極限性能的情境下比 ext4 快一些。

憑著印象,加上查了說明確認,ResierFS 應該是在小檔時會有優勢:

Compared with ext2 and ext3 in version 2.4 of the Linux kernel, when dealing with files under 4 KiB and with tail packing enabled, ReiserFS may be faster.

不過這是前 SSD 時代的產物了,但也沒有看到後續的比較了...