Category: Linux

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 年十二月...

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 時代的產物了，但也沒有看到後續的比較了...

Mac (M1/M2) 上的 Asahi Linux 支援 OpenGL ES 3.1

在「The first conformant M1 GPU driver」這邊看到 Mac (M1 系列與 M2 系列) 上的 Asahi Linux 支援 OpenGL ES 3.1 了。

文章裡面有提到，目前 macOS 上沒有業界標準介面可以用：

Unlike ours, the manufacturer’s M1 drivers are unfortunately not conformant for any standard graphics API, whether Vulkan or OpenGL or OpenGL ES. That means that there is no guarantee that applications using the standards will work on your M1/M2 (if you’re not running Linux).

也許有機會會看到有人 backport 回 macOS 上？

musl 的 DNS reolsver 支援 TCP fallback

在 Facebook 上看到這篇：

剛好想起前陣子在 Hacker News 上看到「Musl 1.2.4 adds TCP DNS fallback (openwall.com)」這個消息，裡面的連結是今年五月 musl 1.2.4 的出版公告：「musl 1.2.4 released」(話說 openwall 網站似乎有擋 HiNet 的 IP，我是走第四台網路看的，或是參考 Internet Archive 上面的連結)。

musl 1.2.4 一個很重要的改變是在 DNS resolver 上支援了 TCP fallback (也就是支援 DNS over TCP)，這改善了長久以來在 container 裡面使用 Alpine Linux 偶而會因為 DNS 遇到沒有照標準做的 server 而中雷的問題：

This release adds TCP fallback to the DNS stub resolver, fixing the longstanding inability to query large DNS records and incompatibility with recursive nameservers that don't give partial results in truncated UDP responses. It also makes a number of other bug fixes and improvements in DNS and related functionality, including making both the modern and legacy API results differentiate between NODATA and NxDomain conditions so that the caller can handle them differently.

查了一下對應的標準，跑去問 ChatGPT 的 GPT-4：

但 ChatGPT 引用的東西都不能直接當作是實際的文字，只能當作一個起點去找。實際翻 RFC 1035 可以翻到：

Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header.

所以的確在 UDP response 的規範是 512 bytes，要取得完整的資料只能往 TCP 查詢。而 musl 有了這個 TCP fallback 總算是補掉了 Alpine Linux 的一個大坑。

而 musl 1.2.4 則是在 Alpine Linux 3.18 才開始使用：「Alpine 3.18.0 released」。

musl libc 1.2.4 – now with TCP fallback in DNS resolver

所以回到開頭，提到 Alpine Linux 3.16 還是有問題的人，是應該會遇到問題沒錯，因為 3.16 的 musl 本來就沒 TCP fallback？遇到不標準的 DNS server 的確是會噴...

Anyway，Alpine Linux 的 DNS 問題應該會變成過去式...

AlmaLinux 放棄 1:1 clone RHEL

上個禮拜的資訊了 AlmaLinux 最後決定放棄 clone RHEL：「The Future of AlmaLinux is Bright」。

After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible*.

這樣在市場上有 Rocky Linux 與 SUSE 也打算要搞自己的 RHEL clone 的前提下，沒有使用 AlmaLinux 的誘因，標題說的 bright 就是講講而已。

strlcpy() 與 strlcat() 被加入 glibc

Hacker News 上看到「Strlcpy and strlcat added to glibc 2.38 (sourceware.org)」這個，印象中極度排斥 strlcpy 與 strlcat 的 glibc 要包進去了。

主要的原因在原始的 commit log 裡面有提到，是因為 POSIX 標準要放入這兩個 function 了：

These functions are about to be added to POSIX, under Austin Group issue 986.

找了一下提到的 Austin Group issue 986，最後更新是 2022 年，看起來進度不快，但是就是一直推進？

反過來看了一下 Hacker News 上的討論，果然有人把當年 Ulrich Drepper 臭 BSD 流派的信件翻出來：「Re: PATCH: safe string copy and concetation」。

玩了一下 OpenSnitch，Linux 下的 Application Firewall

這是在 Hacker News 上的討論「Brute-forcing a macOS user’s real name from a browser using mDNS (fingerprint.com)」這篇看到的，裡面一開始是提到 Mac 上面的 Little Snitch，可以針對特定應用程式設定防火牆規則，而在 Linux 上對應的解決方案則是 OpenSnitch，但一直沒有嘗試，所以就試著用看看...

套件分成兩個部分，一個是 OpenSnitch 的主程式，另外一個是 GUI 的部分。

而在 Ubuntu 22.04 上裝有點麻煩，因為 Ubuntu 22.04 上預設的 grpc package 似乎是有 bug，需要裝新版解決。

不過我在找 PPA 的時候發現有人包了輔助套件：「OpenSnitch - application firewall (Xenial & newer)」。

這個套件本身是沒有包 OpenSnitch 主程式與 GUI 套件的，他只是要「補充」官方套件安裝的問題，所以需要照他的說明安裝：(我把下面指令提到的 1.5.2 換成目前新版的 1.6.0 裝，目前看起來是會動的)

sudo add-apt-repository ppa:savoury1/opensnitch
sudo apt-get update && sudo apt-get upgrade
sudo dpkg -i opensnitch_1.5.2-1_amd64.deb
sudo dpkg -i python3-opensnitch-ui_1.5.2-1_all.deb
sudo apt-get -f install

這邊用 dpkg -i 裝，而不是用 apt install 的原因是故意讓他不裝 dependency，等到後面的 apt-get -f install 時再裝 PPA 裡面提供的 dependency。

裝好後把跑 opensnitch-gui 起來後就會陸陸續續收到系統內不同的應用程式嘗試的連線，像是官網提供的 screenshot 這樣 (會跳出像左邊這樣的視窗)：

這樣可以控的比較細，不過剛開始用會需要花時間把系統內常態性的 request 先設定過一次，還蠻煩的 XD

SUSE 參戰：SUSE 宣佈投入 RHEL clone

Hacker News 上看到「SUSE is forking RHEL (suse.com)」這個，原文的確就是 SUSE 決定參戰，跳進去 clone RHEL：「SUSE Preserves Choice in Enterprise Linux by Forking RHEL with a $10+ Million Investment」。

第一段把重點講完了，手上自己有 SUSE Linux Enterprise 的 SUSE 決定要維護一套 RHEL clone：

Today SUSE, the company behind Rancher, NeuVector, and SUSE Linux Enterprise (SLE) and a global leader in enterprise open source solutions, announced it is forking publicly available Red Hat Enterprise Linux (RHEL) and will develop and maintain a RHEL-compatible distribution available to all without restrictions. Over the next few years, SUSE plans to invest more than $10 million into this project.

然後 Hacker News 討論裡面看到這個資訊頗有趣：SUSE 的 CEO Dirk-Peter van Leeuwen 才來三個月，先前在 Red Hat 待了十八年：

> Dirk-Peter van Leeuwen, CEO of SUSE, said,

According to LinkedIn Dirk-Peter started at Suse 3 months ago as CEO and worked for Red Hat for 18 years and was a Senior VP at Red Hat.

I think this move of Suse could be a credible threat to IBM / Red Hat's RHEL.

看 LinkedIn 上的經歷，應該算是純業務出身... 這算是什麼操作？

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 的法務給補上？