Android 的 Linux Kernel 將會有四年的維護期

去年 Linux Kernel 決定將 LTS 從六年縮短為兩年 (參考先前寫到的「Linux Kernel 後續的 LTS 版本將縮短成兩年」),而 Android 這邊決定後來的 LTS 版本將額外提供兩年支援,變成四年:「Google extends Linux kernel support to keep Android devices secure for longer」,引用的報導在「Google extends Linux kernel support to keep Android devices secure for longer」。

Android 的說明文件「Android common kernels」這邊有提到這個時間:

Beginning with kernel 6.6, the support lifetime for the stable kernels is 4 years.

應該是 Android 本身的 support policy 需要這個長度...

MySQL 8.4.0 出版

這是 LTS 版本,可以預期後續 Percona 也會準備對應的 distribution 使用。

先查了一下 MySQL 8.0 的 EoL 日期,目前是訂在 2026/04/30,大約還有兩年的時間可以準備。

回來看 8.4,從「What Is New in MySQL 8.4 since MySQL 8.0」這邊可以看到官方整理與 8.0 的差異。

InnoDB 這邊有不少預設參數調整,算是配合現在硬體愈來愈好而調整的數字。

在「MySQL Replication: tagged GTIDs」這邊有提到 replication 時用到的 GTID format 有更新,多了 tag 的欄位。看起來在 upgrade 時會相容舊格式,但要 rollback 或是 downgrade 時得注意到這邊的問題...

然後在「Replication SQL syntax」這邊有提到移除掉很多舊語法,像是 CHANGE MASTER TORESET MASTER 這種語法都被改成新的語法了,要重新背。

整體看起來沒有太多變化?

Ubuntu 的 LTS 從 10 年變成 12 年

積了一個多月的東西,Canonical 宣佈 UbuntuLTS 從 10 年變成 12 年 (付費版本):「Canonical expands Long Term Support to 12 years starting with Ubuntu 14.04 LTS」,這個改變會包括 (三月當時) 快要滿十年的 14.04 (trusty) 以及之後的版本:

Today, Canonical announced the general availability of Legacy Support, an Ubuntu Pro add-on that expands security and support coverage for Ubuntu LTS releases to 12 years. The add-on will be available for Ubuntu 14.04 LTS onwards.

應該是被不少既有客戶要求後發現有市場,所以就決定先延個兩年看看?

寫這篇才意外注意到 Ubuntu 14.04 到現在也已經十年了,這幾天在看 Travis CI 的資料,發現這個平台支援一堆古董,可以看到 Ubuntu 12.04 (precise) 的 image,而且最新也才支援到 Ubuntu 20.04 (focal):「Build Environment Overview」。

AWS 宣布 EKS 支援期從 14 個月變成 26 個月

有訂 RSS feed 但應該是漏看了,後來在 X (Twitter) 上看到 qrtt1 轉貼 ingramchen 的貼文才注意到的,AWS 宣布 EKS 支援期從本來的 14 個月 (跟 k8s 官方相同) 變成 26 個月 (多了一年):

公告在「Amazon EKS Extended support for Kubernetes Versions now available in preview」以及「Amazon EKS extended support for Kubernetes versions available in preview」這邊。

這邊查了資料發現有點複雜,KEP-2572: Defining the Kubernetes Release Cadence 這邊有正式的說明,但「Kubernetes | endoflife.date」這邊比較清楚 14 個月是怎麼來的:

Kubernetes follows an N-2 support policy (meaning that the 3 most recent minor versions receive security and bug fixes) along with a 15-week release cycle. This results in a release being supported for 14 months (12 months of support and 2 months of upgrade period).

雖然是付費功能,但目前這個功能是 preview,代表不受到 SLA 之類的保障,應該是之後成熟了再看情況變成 GA:

Today, we’re announcing the preview of Amazon Elastic Kubernetes Service (EKS) extended support for Kubernetes versions. You can now run Amazon EKS clusters on a Kubernetes version for up to 26 months from the time the version is generally available on Amazon EKS. Extended Support is available as a free preview for all Amazon EKS customers, starting today with Kubernetes version 1.23.

算是還不錯的消息?就目前看到的經驗,每次的升級都會爛掉不少東西,所以沒用到新功能卻被迫要更新的次數可以降低一些,總是好事...

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

Java 21 (LTS) 推出

Hacker News 上注意到 Java 21 的消息:「JDK 21 Release Notes」、「Java 21 / JDK 21: General Availability」、「OpenJDK JDK 21 General-Availability Release」。

對於沒什麼在寫 Java 的人來說 (也是等於比較沒有在接觸 Java 圈子消息的人),比較意外的是這是推出的是 LTS 版本,距離上次的 LTS (Java 17) 才兩年前 (2021/09/14):

JDK 21 will be a long-term-support (LTS) release from most vendors, including Oracle. If you’re upgrading from the previous LTS release, JDK 17, then you have many more JEPs to look forward to, summarized here:

翻了一下 Java version history,可以知道同時支援的 LTS 版本變成四個了,而最近一次會終止的會是 Java 11,Red Hat 會在 2024/10 終止,而 Oracle 會在 2026/09 終止,這中間還會不會再增加 LTS...?

雖然沒什麼在寫,但還是常常會看到有人提到這次引入了 Virtual ThreadsGenerational ZGC,這應該是討論度最高的。

看了 Virtual Threads 的說明,有種「反璞歸真」的感覺...

在二十年前的時候,就已經有很多 userland threading library,讓應用程式可以用 threading design pattern 開發程式,而當時 x86 下的作業系統開始要遇到多 CPU 的環境,才開始在 kernel 裡支援 threading,讓應用程式裡面的 threading 可以打散到多個不同的 CPU 上面。

記得當年 FreeBSD 4 之後對 SMP 與 threading 的爭論導致分家出 DragonflyBSD,而 FreeBSD 的多 CPU 效能與穩定性要一直到 FreeBSD 7 才穩了下來。

現在 Java 反過來為了降低 OS thread 造成的 overhead,讓 java.lang.Thread 可以跑在 userland 裡面,不要用 kernel 提供的 OS thread...

另外又讓我想到 kqueueepoll 以及 libevent 的事情了,不過這扯遠了...

MySQL 改變發佈的方式,推出 LTS 版本

看到 Percona 寫的「LTS and Innovation Releases for Percona Server for MySQL」這篇,才注意到 Oracle 宣佈了 MySQLLTS 版本:「Introducing MySQL Innovation and Long-Term Support (LTS) versions」。

這次的改變產生了 Innovation 版本與 LTS 版本:

We're transitioning to the new MySQL versioning model with our upcoming versions. MySQL database version 8.1.0 will be our first Innovation release, and 8.0.34+ will transition to only bug fixes until 8.0 End-Of-Life (EOL) scheduled for April-2026. Approximately one year from now, MySQL version 8.x will eventually become LTS which will provide ample time for users to migrate from 8.0.x to the 8.x LTS version.

從這段的解釋看起來是在講從舊的發佈模式到新的發佈模式的轉換期特例,MySQL 8.0.34+ (應該是指 8.0 的後續這條,從 8.0.34 開始) 會支援到 2026 年四月,大約是再兩年半多;而 8.x (應該是指 >8.0 的這條?) 會在距今一年後 (大約是 2024 年年中?) 成為 LTS 版本。

接著的段落拿了一些範例說明:

In practice, in this transition period, if you want the latest features, improvements, and all bug fixes for your MySQL databases, use the Innovation release track (eg., 8.1.x, 8.2.x, 8.3.x, etc.). If you need only bug fixes for your MySQL database, use 8.0.x releases (eg., 8.0.35, 8.0.36, 8.0.37, etc.). In both cases, you should plan to update your MySQL databases quarterly accordingly to Oracle Critical Patch Updates (CPU) calendar. When 8.x becomes LTS, you can plan, test, and migrate from the 8.0.x bug fix track to the LTS release track (ex., from 8.0.37 to 8.4.1).

看起來 8.0 是轉換期的特殊待遇,看起來有點像是 LTS 的 security update only?然後是官方給的這張圖,要注意這張圖下面有提到這張圖只是示意,實際發生的時間點可能會有改變,不過也可以看出來在 8.0 的地位比較特別:

Note that this is an example, there is no commitment that the version numbering will be exactly as presented.

而 LTS 的頻率會是兩年一版,支援 5+3 年,而 8.0 會走四年半:

About every 2 years, a minor version will be designated as Long Term Supported release. This version will have a 5 year premier and 3 year extended support, the same as the previously supported releases. This is similar to MySQL 5.7 and previous releases.

The LTS will also be the last version of the major release. The next (Innovation) release will increase it's major version. For example if MySQL 8.4.0 is the 8.x LTS release, then MySQL 9.0 will be the next Innovation release.

另外後面有提到他們會確保 LTS 在升級時會用到的方式,看了一下沒有太多意外,跟之前在 5.x 年代的感覺差不多。

倒是降級這件事情他們也提出方案,這點就蠻值得看一下了... 然後這邊可以看到 async replication 果然超萬用的。

基本上就是 release cycle 改變的公告,現在這個階段繼續黏在 8.0 上面應該就可以了,後續等第一個 LTS 的消息。

Imgur 改變使用條款,把 Imgur 的圖片都搬回本機上

Hacker News 上看到 Imgur 的使用者條款改變的消息:「Imgur will ban explicit images on its platform this month」,在 TechCrunch 文章標題提到的東西對 blog 影響不大,反倒是公告裡面另外提到的事情比較傷。

Imgur 在「Imgur Terms of Service Update [April 19, 2023]」這邊提到了:

Our new Terms of Service will go into effect on May 15, 2023. We will be focused on removing old, unused, and inactive content that is not tied to a user account from our platform as well as nudity, pornography, & sexually explicit content.

所以很少被存取的內容也會有機會被移除掉,這導致一堆小的 blog 或是 forum 用到的內容也會爛掉。

所以決定先搬出來,掃了一下 WordPress 資料庫裡面的內容,把檔案先拉下來,弄個 CloudFront 擋在前面 (有 free quota 的關係),然後把資料庫裡面的連結整批換掉。

另外是新的內容要丟哪裡,所以用 PHP 寫了一個很簡單的 self-hosted image server,程式碼在 GitHub 上面可以翻到:「i.gslin.com」。

裡面除了 PHP 以外,也練了一下 javascript,收 paste 事件把 image/png 的資料用 fetch() 傳到 server 端處理。

現在功能還很陽春,但至少能開始用,之後再逐步加功能上去。等功能變多變複雜之後,可能會用 Composor 掛套件上去... 但現在還算簡單,一個 upload.php 處理所有事情就好。

Canonical 推出 Ubuntu Pro

Canonical 推出了 Ubuntu Pro,個人用戶以及小型商業用戶可以免費安裝在五台機器上使用:「Canonical launches free personal Ubuntu Pro subscriptions for up to five machines」。

這次是 public beta,這代表進到正式版本的時候也許還會有變化:

Ubuntu Pro, the expanded security maintenance and compliance subscription, is now offered in public beta for data centres and workstations.

這次推出的 Ubuntu Pro 看起來包括了 ESM (但這邊沒有提到 ESM,而是提到了十年的安全更新);除了 ESM 以外,包括了更多 package 的安全更新,一併提供十年:

Ubuntu Pro (currently in public beta) expands our famous ten-year security coverage to an additional 23,000 packages beyond the main operating system.

Including Ansible, Apache Tomcat, Apache Zookeeper, Docker, Drupal, Nagios, Node.js, phpMyAdmin, Puppet, PowerDNS, Python 2, Redis, Rust, WordPress, and many more...

不過看起來的確就是將 ESM 擴大,這點在 Ubuntu Pro 的價錢的頁面上「Ubuntu Pro | plans and pricing」可以看到有提到 ESM。

但要注意 14.04 雖然有 ESM (照時程表算的話會支援到 2024 年),卻不在這次 Ubuntu Pro 提供的範圍,這次推出的 Ubuntu Pro 是 16.04 以及之後的版本才有:

Ubuntu Pro is available for every Ubuntu LTS from 16.04 LTS. It is already in production for large-scale customers offering global services.

然後本來的 Ubuntu Advantage for Infrastructure 這條產品線改名為 Ubuntu Pro (Infra-only):

Ubuntu Advantage for Infrastructure is now rebranded to Ubuntu Pro (Infra-only). The features and price have not changed.

目前手上沒有 16.04 的機器,等明年 2023 看看 18.04 的機器有沒有換到 20.04/22.04,如果沒有的話也許可以來玩看看...

Let's Encrypt 更新了 ToS

在「Let's Encrypt’s subscriber agreement changes on Sept 21 (letsencrypt.org)」這邊看到的,Let's Encrypt 有提供 diff 的內容,在「LE-SA-v1.2-v1.3-diff.docx」這邊,你也可以用 Google Docs Viewer 看:「LE-SA-v1.2-v1.3-diff.docx」。

看起來主要是用語上的改變 (可能是律師的建議?),除了 revoke 的章節外看起來沒什麼大變化。而 revoke 的章節部份增加了這兩段文字:

You warrant to ISRG and the public-at-large, and You agree, that before providing a reason for revoking Your Certificate, you will have reviewed the revocation guidelines found in the “Revoking Certificates” section of the Let’s Encrypt documentation available at https://letsencrypt.org/docs/ , and that you will provide Your corresponding revocation reason code with awareness of such guidelines.

You acknowledge and accept that ISRG may modify any revocation reason code provided by You if ISRG determines, in its sole discretion, that a different reason code for revocation is more appropriate or is required by industry standards.

不確定自動化的 client 需不需要重新再 accept 一次?