Tag: support

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.

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

最近 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).

Python 3 的支援週期

印象中之前有找過資料應該有寫過，但搜了一下沒翻到，可能是當初寫一寫刪掉了？

Python 的支援週期在「Status of Python versions」這頁可以看到，只看 Python 3 的部分的話，可以看出來從 3.2 之後的版本都是固定五年：

五年剛好與 Ubuntu 的 LTS 相同，好像有點微妙... 會遇到 Ubuntu 的 LTS 支援快要結束的時候，官方的支援也已經結束了，所以也的確有看到 18.04 (bionic) 後續的更新把 python3-minimal 升級到 3.8 版 (2019/10/14 出)。

看起來 20.04 (focal) 也會遇到類似的問題，目前的 python3-minimal 是 3.8.2-0ubuntu2，到 2024 年十月終止，而 20.04 (focal) 的 LTS 到 2025 年四月，應該也會生個版本？

cURL 放入 ipfs:// 支援

在 Hacker News 上看到 cURL 支援 ipfs:// 的消息：「IPFS support got merged into curl (twitter.com/bmann)」。

Hacker News 上有人提到這包支援的特性與問題：

This patch makes curl utilize a gateway for ipfs:// addresses. It prefers a local one but can also use public gateways. It makes no effort to verify that the final product's cryptographic hash corresponds to the one in the address.

依照說明是透過 gateway 處理，如果本地端有的話就用本地端的 gateway，不然就用 public gateway。另外就是沒有驗證 hash...

不算是原生支援，但還行...？

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 Threads 與 Generational 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...

另外又讓我想到 kqueue、epoll 以及 libevent 的事情了，不過這扯遠了...

OpenSSL 1.1.1 EoL

看到 OpenSSL 官方的公告，1.1.1 版 EoL：「OpenSSL 1.1.1 End of Life」(btw，我不知道他們為什麼網址上會放兩個 /blog/...)。

OpenSSL 1.x 與 3.x 最大的差異就是他的 license 了，1.x 版是 dual license，但這兩個 license 都與 GPL 不相容：

OpenSSL was dual-licensed under the OpenSSL License and the SSLeay License, which means that the terms of either licenses can be used. The OpenSSL License is Apache License 1.0 and SSLeay License bears some similarity to a 4-clause BSD License.

As the OpenSSL License was Apache License 1.0, but not Apache License 2.0, it requires the phrase "this product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit" to appear in advertising material and any redistributions (Sections 3 and 6 of the OpenSSL License). Due to this restriction, the OpenSSL License and the Apache License 1.0 are incompatible with the GNU GPL.

後續 3.x 的版本則改成 Apache License 2.0 了：

OpenSSL announced in August 2015 that it would require most contributors to sign a Contributor License Agreement (CLA), and that OpenSSL would eventually be relicensed under the terms of Apache License 2.0.

不過 Apache License 2.0 與 GPLv2 還是不相容 (但相容於 GPLv3)，這個更換只是換成一個比較常見的 license：

The Free Software Foundation considers all versions of the Apache License to be incompatible with the previous GPL versions 1 and 2.

話說 Ubuntu 20.04 內的 OpenSSL 是 1.1.1f，看起來光是標準的 LTS (到 2025/04) 期間都得自己維護了？其他作業系統應該也會有類似的問題...

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

看到 Percona 寫的「LTS and Innovation Releases for Percona Server for MySQL」這篇，才注意到 Oracle 宣佈了 MySQL 的 LTS 版本：「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 的消息。

nginx 開始嘗試支援 HTTP/3

Hacker News 上看到「Nginx 1.25.0: experimental HTTP/3 support (nginx.org)」這則消息，從 nginx 1.25.0 開始可以用 HTTP/3。

與 HTTP/2 最大的差異就是從以往的 TCP 改到 UDP 上了，這是基於 QUIC 的經驗弄出來的東西...

nginx 的支援算是等了一陣子了，不過沒有當初 HTTP/1.1 到 SPDY 的進步這麼明顯，我自己就沒有跟的那麼緊了。

這樣以後 office firewall 預設應該會再開 443/udp？

llama.cpp 開始支援 GPU 了

前陣子因為重灌桌機，所以在重建許多環境... 其中一個就是 llama.cpp，連到專案頁面上時意外發現這兩個新的 feature：

OpenBLAS support
cuBLAS and CLBlast support

這代表可以用 GPU 加速了，所以就照著說明試著編一個版本測試。

編好後就跑了 7B 的 model，看起來快不少，然後改跑 13B 的 model，也可以把完整 40 個 layer 都丟進 3060 (12GB 版本) 的 GPU 上：

./main -m models/13B/ggml-model-q4_0.bin -p "Building a website can be done in 10 simple steps:" -n 512 -ngl 40

從 log 可以看到 40 layers 到都 GPU 上面，吃了 7.5GB 左右：

llama.cpp: loading model from models/13B/ggml-model-q4_0.bin
llama_model_load_internal: format     = ggjt v2 (latest)
llama_model_load_internal: n_vocab    = 32000
llama_model_load_internal: n_ctx      = 512
llama_model_load_internal: n_embd     = 5120
llama_model_load_internal: n_mult     = 256
llama_model_load_internal: n_head     = 40
llama_model_load_internal: n_layer    = 40
llama_model_load_internal: n_rot      = 128
llama_model_load_internal: ftype      = 2 (mostly Q4_0)
llama_model_load_internal: n_ff       = 13824
llama_model_load_internal: n_parts    = 1
llama_model_load_internal: model size = 13B
llama_model_load_internal: ggml ctx size =  90.75 KB
llama_model_load_internal: mem required  = 9807.48 MB (+ 1608.00 MB per state)
llama_model_load_internal: [cublas] offloading 40 layers to GPU
llama_model_load_internal: [cublas] total VRAM used: 7562 MB
llama_init_from_file: kv self size  =  400.00 MB

30B 的 model 我也試著丟上去跑，但只能丟 28 layers 上去 (全部是 60 layers)，再多 GPU 的記憶體就撐不住了。

但能用 GPU 算是一個很大的進展，現在這版只快了一半的時間，不知道後面還有沒有 tune 的空間...