Ubuntu 14.04 與 16.04 的 ESM 從八年延長到十年

本來的舊的 Ubuntu ESM 是額外的三年 (加上本來的 LTS 五年,共八年),14.04 會支援到 2022 年四月 (參考 Internet Archive 上的存檔資料「Ubuntu 14.04 LTS has transitioned to ESM support」),然後 16.04 會支援到 2024 年四月 (參考 Internet Archive 上的存檔資料「Ubuntu 16.04 LTS transitions to Extended Security Maintenance (ESM)」),而 18.04 與 20.04 以後的 Ubuntu ESM 則是額外五年。

現在則是宣佈 14.04 與 16.04 都切齊額外五年了,所以總共都是十年:「Ubuntu 14.04 and 16.04 lifecycle extended to ten years」。

另外在 Hacker News 上的討論可以看一下:「Ubuntu 14.04 and 16.04 lifecycle extended to ten years (ubuntu.com)」,有人覺得這個政策很糟,但我覺得還好,有些商業環境就是花錢解決懶得升級... (沒有 support 只有 security update 的方案,一台實體機器才 USD$225/year,如果是虛擬機的話就更便宜了)

算是對付 legacy application 還蠻重要的方案...

Java 17 (JDK 17),新的 Java LTS 版本 (然後來看 GC)

Java 17 (JDK 17) 釋出,這是 Oracle 本家新的 LTS 版本,引用的是 jdk-dev 的 mailing list:「Java 17 / JDK 17: General Availability」。另外在 Hacker News 上的討論可以翻一下:「Java 17 / JDK 17: General Availability (java.net)」。

上一個 LTS 版本是 Java 11,所以很自然的也會有從 Java 11 之後的新功能說明:「JEPs in JDK 17 integrated since JDK 11」。

對於只是拿來用,而不是拿來開發的人來說,我的重點都放在 JVM 的 GC 效能以及特性。

從 Java 11 預設的 G1GC 來看,可以看到一些改善,從「JEP 345: NUMA-Aware Memory Allocation for G1」(Java 14) 這個看起來會改善 G1GC 在多實體 CPU 的情況下效能,不過看起來有 -XX:+UseNUMA 這個參數要加。

再來是「JEP 346: Promptly Return Unused Committed Memory from G1」(Java 12) 可以在閒閒的時候跑個 GC 把記憶體給 OS。

接下來是兩個新的 GC (相較於 11 版),一個是 ZGC,另外一個是 Shenandoah,都沒有取代 G1GC,但兩個都有對應使用的場景。

ZGC 有列兩個 JEP:「JEP 376: ZGC: Concurrent Thread-Stack Processing」、「JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)」,目標是讓 GC pause time 盡可能的低,另外在 wiki 上面的說明則是有提到目標在 1ms 以下:

The ZGC garbage collector (GC) aims to make GC pauses and scalability issues in HotSpot a thing of the past.

Sub-millisecond max pause times

Shenandoah 列出了「JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)」,不過先前的「JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)」講的比較詳細,目標是希望 GC 不影響目前正在執行的程式:

Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB.

可以看出來兩個新的 GC 都是希望降低 pause time,對於 latency 敏感的應用應該都可以測試看看,可以預期整體的 throughput 會低一些。

回頭來看 G1GC,有人跑了 benchmark 測試了 Java 11 與 Java 17 的 G1GC 差異:「How much faster is Java 17?」。

可以看到 G1GC 的改善 (藍色的部份) 看起來還是不少,不過有些情況下是會變慢的。文章裡面還有提到 Parallel GC,這邊就不提了,可以自己看...

等各家 build 出來後來測看看 Cassandra 的效能影響如何...

Django 3.2 LTS

Django 3.2 LTS 出了:「Django 3.2 released」,對應的 release note 可以在「Django 3.2 release notes」這邊看到。

這個版本比較特別,一般版本提供大約 15 個月的支援,LTS 版本則提供 36 個月的支援,不過目前用起來的感覺還是鼓勵大家平常就要安排升級計畫,不然 3.2 升級到 4.2 鐵定是個超痛苦的過程。

昨天把 Django 3.1 的專案升級上 3.2 後,跑 test case 就遇到「Customizing type of auto-created primary keys」這邊描述的問題,目前先用 DEFAULT_AUTO_FIELD = 'django.db.models.AutoField' 解,其他的倒是沒什麼問題...

幾個我覺得有趣的,像是 JSONL 格式:

The new JSONL serializer allows using the JSON Lines format with dumpdata and loaddata. This can be useful for populating large databases because data is loaded line by line into memory, rather than being loaded all at once.

然後不支援 PostgreSQL 9.5 與 MySQL 5.6 了:

Upstream support for PostgreSQL 9.5 ends in February 2021. Django 3.2 supports PostgreSQL 9.6 and higher.

The end of upstream support for MySQL 5.6 is April 2021. Django 3.2 supports MySQL 5.7 and higher.

很久前寫 Django 1.x,然後就荒廢很久,最近是從 3.0 開始寫,有些東西熟一點以後覺得怪怪的,之後要找時間測一些東西,修正對 Django 的用法。

Mattermost 推出了 ESR 5.31

在「Support for ESR 5.25 is ending」這邊看到 Mattermost 新的 ESR (Extended Support Release) 釋出了,也就是 5.31 版。

不過看了一下發現 support 期間還是很短,一般的 release 是三個月,ESR 也才九個月:

另外一個大問題是在行動平台上多帳號的支援,官方在「Mobile Apps FAQ」有提到這個問題,然後也有解釋技術上的問題,不過從 issue tracking system 可以看到官方對這個 feature 進展不怎麼快:

At the moment, we only support connecting to one server at a time; however, we are aware that this is one of the top feature requests for the mobile app. We are currently investigating some technical challenges, such as how to handle push notifications coming from multiple servers. To follow our progress on this feature, you can join the RN: Multi-Server channel on our community server.

先繼續丟著...

EFS 上可以掛 AWS Transfer Family 了

先前 AWS Transfer Family 的後端只能是 Amazon S3,現在則是宣佈可以掛 Amazon EFS 了:「New – AWS Transfer Family support for Amazon Elastic File System」。

EFS 跟 S3 都是沒有空間限制,但 EFS 可以直接在系統上掛起來當作一般的檔案系統用,基本上就是更方便,不過代價就是單位儲存成本貴不少...

這次支援 EFS 對於一些量不大的處理又方便不少,也就是處理完後的檔案另外丟,而上傳上來的檔案可以砍掉的... 如果是上傳上來的檔案需要保留的,用 S3 會比較適合。

AWS 淘汰 Amazon RDS (MySQL 5.5) 的計畫

AWS 規劃要淘汰 Amazon RDS (MySQL 5.5),不過我是從 Percona 這邊看到...:「Amazon RDS for MySQL 5.5 EOL Date is Approaching – Act Now!」,找了一下官方的文件,在「Announcement: Amazon RDS for MySQL 5.5 End-of-Life date is approaching」這邊可以翻到。

如果硬要待在 MySQL 5.5 的話,目前看起來比較容易的解法應該是自己用 EC2 架,不過這樣的話 High Availability 的架構就頗麻煩了,用 ELB 可能是個方法...

話說回來,好久沒用 MySQL 5.5 了,這個版本記得是 InnoDB Plugin 整合進 MySQL 的第一個版本,先前應該是 MySQL 5.1 + InnoDB Plugin 的方式跑,我記得當時就是要 COMPRESSED 格式,算是 MySQL 當時蠻重大的進展...

手上還有在 5.5 上跑的人應該要自己安排時間換,儘量不要等到 AWS 硬升級的時候換,這樣炸掉的機會蠻高的...

Canonical 與 Docker 合作,推出了一系列 LTS Docker Image

CanonicalDocker 合作,推出了一系列 LTS Docker Image:「Canonical publishes LTS Docker Image Portfolio on Docker Hub」。

這邊的 LTS 是十年:

Ten year maintenance commitment on app images provides secure cloud software supply chain

另外有提到這些 LTS Docker Image 將不受 per-user rate limit 限制:

Canonical and Docker will collaborate on Docker Official Images and LTS Docker Image Portfolio to bring the best of the two to the community and ecosystem. The entire LTS Docker Image Portfolio will be exempted from per-user rate limits.

發佈的 image 可以在 https://hub.docker.com/u/ubuntu 上面翻到,主要就是常見的 server 軟體,算是多一個選擇...

用 Amazon SNS 送簡訊可以固定發送號碼了

Amazon SNS 的簡訊功能可以申請固定發送號碼了:「Amazon SNS now supports selecting the origination number when sending SMS messages」。

固定的號碼包括了短碼與長碼:「Requesting dedicated short codes for SMS messaging with Amazon SNS」、「Requesting dedicated long codes for SMS messaging with Amazon SNS」。

短碼是三到七碼,依照地區而有差異:

A short code typically contains between three and seven digits, depending on the country or region that it's based in.

要注意的是短碼的部份需要開 support case 申請,而不是直接在 web console 上操作:

Open a case with AWS Support by completing the following steps.

長碼則是有可能到 12 碼,依照不同地區的設計有所不同:

A long code (also referred to as a long virtual number, or LVN) is a standard phone number that contains up to 12 digits, depending on the country that it's based in.

不過現在長碼的部份只有美國可以用,而且有速率限制:

Support for long codes is restricted to the United States only. Sending rates for long codes are restricted to 1 message per second. This restriction is set by the telecom carriers, and isn't a limitation of Amazon SNS. If you send a large volume of messages from a long code, wireless carriers might begin to block your messages. Your applications that use Amazon SNS should limit the number of messages that they send each second.

說道 Amazon SNS 送簡訊的費用,實在不怎麼好看,量小加減用 (包在 AWS 費用裡,省人力另外跑請款的單子),量大還是要找其他家接比較划算...

Chrome 85 支援 AVIF

看到「How to Use AVIF: The New Next-Gen Image Compression Format」這篇在推銷用 AVIF 取代 JPEGWebP

首先是跑去 Can I Use 翻,發現 Google Chrome 85 之後支援了,另外在「Issue 960620: Support AVIF」這邊可以看到對應的 ticket,以及「AVIF Image Decode」這邊有狀態:

Enabled by default (tracking bug) in:
Chrome for desktop release 85

現在的 stabel channel 是 84,所以是下個 release 就會有了。以 Google Chrome 的市占率來說,推出來等於是支援度直接過半... 這點也的確有人批評,不過又是另外一個話題了。

對於不支援 AVIF 的瀏覽器,也有對應的 polyfill 可以上 (用 javascript 去補功能),不過因為是透過 AV1 codec,能夠向下支援的版本還是不多,除非連 AV1 都透過 polyfill 支援:「AVIF (AV1 Still Image File Format) polyfill for the browser」。

另外在寫「WebP 的檔案大小未必比 JPEG 小...」這篇時有提過 AVIF 其實也不是完美的,畢竟是從 video codec 演化來的演算法,對於演算法判斷不重要的部位會掉比較多細節...

Ubuntu 16.04 出更新了...

看到 Ubuntu 16.04 (xenial) 在 support cycle 剩下不到一年的時候推出了 16.04.7:「Ubuntu 16.04.7 LTS released」。

看起來主要是修正 GRUB 的安全性問題:「USN-4432-1: GRUB 2 vulnerabilities」。

這次修正的 CVE 好像有點多,但全部都是與 GRUB 相關的... 另外可以看到包括 14.04 (trusty) 都有修正 (ESM,付費提供支援的版本)。

目前手上大多數機器都是 18.04 (bionic) 與 20.04 (focal) 了,會在 16.04 (xenial) 主要是 OpenVZ 的關係,雖然看起來還是有一台一直懶得動,該找機會弄一弄了...