MySQL 5.7 已經 EoL

查資料發現忘記這件事情了... 先前就有寫過 MySQL 5.7 到今年十月就 EoL 了:「MySQL 5.7 的支援只到今年十月 (Oct 2023)」。

最後一版是 2023/10/25 釋出的 5.7.44:「Changes in MySQL 5.7.44 (2023-10-25, General Availability)」。

MySQL 5.7.44 is the final release of the MySQL 5.7 series.

然後 MySQL 8.1 也是十月 EoL。

雖然目前已經有 MySQL 8.2 了,但 MySQL 8.0 是 LTS,目前預定支援到 2026 年四月 (大約還有兩年多),所以除非有需要用到 MySQL 8.2 的新功能或是特性,不然應該還是會先繼續用 MySQL 8.0...

然後翻了一下 Percona Server for MySQL,看起來還是沒有提供 ARM 的 binary 可以裝,所以在 ARM 上面的機器比較方便的還是裝 MariaDB 了...

Django 5.0

Django 5.0 的消息出來了:「Django 5.0 released」,比較完整的 release notes 則是在這邊:「Django 5.0 release notes」。

對應的 Django 4.2 因為是 LTS,會支援到 2026/04:

With the release of Django 5.0, Django 4.2 has reached the end of mainstream support. The final minor bug fix release, 4.2.8, was issued today. Django 4.2 is an LTS release and will receive security and data loss fixes until April 2026. All users are encouraged to upgrade before then to continue receiving fixes for security issues.

Django 5.0 比較大的 incompatibility 會是 Python 版本的要求:

Django 5.0 supports Python 3.10, 3.11, and 3.12. We highly recommend and only officially support the latest release of each series.

The Django 4.2.x series is the last to support Python 3.8 and 3.9.

關於 Python 版本的部分,交叉參考「Status of Python versions」這邊的說明,可以看到目前還在提供安全性更新 (狀態是 security) 的 3.8 (到 2024/10) 與 3.9 (到 2025/10) 在 Django 5.0 被放掉了...

現在 Django 的大版號更新比較像是常態性把有破壞相容性的更新整理起來出新版,倒不是動到什麼大結構...

Trino Gateway

先前一直有在追蹤 TrinoHA 方案:「High Availability #391」,昨天看到有人更新消息,提到 Trino Gateway 這個專案,以及九月底的時候的公告:「Trino Gateway has arrived」。

主要是從 Presto Gateway 整理出來的:

The release is the result of many, many months of effort to move the legacy Presto Gateway to Trino, start a refactor of the project, and add numerous new features.

原始的 Presto Gateway 專案上面也已經標示後續請大家去看 Trino Gateway:

NOTE: This is a legacy version of Trino Gateway. Please refer to https://github.com/trinodb/trino-gateway for active development and updates moving forward.

然後 Release notes 這邊可以看到前幾天又出一個新版了,看起來是有能量在專案上的。

從「Design」這頁可以看到軟體本身分成 BaseApp、ProxyServer 與 Gateway 三個部分,架構面上可以看得出來是 Proxy 架構。

從「References」這頁可以看到一些組織使用前身 Presto Gateway 的心得:

目前應該會需要一些時間,把積在 backlog 的功能開發出來。之後如果還有遇到 Trino 的話可以拿出來重新研究發展到什麼地方...

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

差不多就這些...

蘋果的衛星 SOS 服務對 iPhone 14 用戶免費延長一年

去年十二月蘋果對 iPhone 14 開通了衛星 SOS 服務:「iPhone 14 的 Emergency SOS via satellite (衛星求救服務) 在北美開通」,然後蘋果決定延長一年:「Apple extends Emergency SOS via satellite for an additional free year for existing iPhone 14 users」。

而且看起來已經開放到十六個區域了:

Now also available on the iPhone 15 lineup in 16 countries and regions, this innovative technology — which enables users to text with emergency services while outside of cellular and Wi-Fi coverage — has already made a significant impact, contributing to many lives being saved. Apple today announced it is extending free access to Emergency SOS via satellite for an additional year for existing iPhone 14 users.

在「Use Emergency SOS via satellite on your iPhone」這邊有找到目前開放的地區,算了一下的確是十六個:

Emergency SOS via satellite is available in Australia, Austria, Belgium, Canada, France, Germany, Ireland, Italy, Luxembourg, the Netherlands, New Zealand, Portugal, Spain, Switzerland, the U.K., and the U.S.

北美洲 (美加) 與大西洋洲 (紐澳) 沒什麼問題,不過歐洲那些區域看起來偏西歐,有點像是衛星訊號的涵蓋性,另外可能還有當地法規的問題?不然以義大利與奧地利的涵蓋範圍,摩納哥與斯洛維尼亞看起來應該也是可以被涵蓋的...

jq 的開發狀況

Hacker News 上看到「Jaq – A jq clone focused on correctness, speed, and simplicity (github.com/01mf02)」這篇的時候,倒不是 jaq 本身如何,而是在 id=38465712 裡面提到了 jq 的發展停滯了五年左右,但最近又恢復了:

Well, taking into account that jq development has been halted for 5 years and only recently revived again, it's no wonder that bug reports have been sitting there for that time, both well known and new ones. I bet they'll get up to speed and slowly but surely clear the backlog that has built up all this time.

然後下面有提到 https://github.com/jqlang/jq/issues/2305#issuecomment-1572634869 這個,今年六月的時候開始重整團隊改善 bus factor,加入更多新的 maintainer 進來。

算是個好消息,朝向 community 的方式來發展...

聊了一下 Amazon S3 Express One Zone 的用途...

昨天寫了「AWS 推出 Amazon S3 Express One Zone」這篇,剛好跟朋友聊了一下 Amazon S3 Express One Zone 的用途...

首先 Amazon S3 Express One Zone 這個產品的定位會是有多台機器需要存取同一包資料:如果是同一台機器要存取的話,放到 Amazon EBS 甚至是 local disk 上就好了。

另外可以知道 Amazon S3 Express One Zone 主要的服務對象不會是靜態資料:靜態資料可以先把所有的資料打包成一大包,丟到標準的 Amazon S3 上面跑,讓每一台機器下載下來,這樣 latency 的影響也會小很多。

所以可以抓到產品的定位:會是有很多機器需要存取同一包資料,而且這包資料會不斷更新。

但畢竟 Amazon S3 Express One Zone 還是要走 HTTPS 去跟 server 要資料,如果你在本地端使用 EBS 或是 local disk,latency 一定還是比較低;而且就程式的開發來說,比較直覺的方法還是在本地端直接弄一個 ext4 filesystem,然後跑很多 process 處理。

(而且這樣還有使用記憶體做的 filesystem cache,加上 EBS 的儲存費用還比 Amazon S3 Express One Zone 便宜)

所以 Amazon S3 Express One Zone 的定位又再被縮小到一台 EC2 instance 沒辦法完成上一段提到的情境。

如果再把前幾天新推出的機器拿來看:「AWS 推出 32TB RAM 的機種 u7in-32tb.224xlarge」,這台新機器是 896 vCPU + 32TB RAM,代表你每跑 896 個 process (假設程式還沒用 threading 打散),而每個 process 可以吃 36GB RAM...

算過以後就會發現,這是個 scale up 可以暴力解很多問題的年代,只要你的演算法不是 n^2 這類的 case...

但回到這個產品的定位,從上面的推敲可以找出還是有對應的需求方,而且知道這是一個比較小眾的產品線,但遇到這種問題的人都會是大型客戶,這樣去思考為什麼會推出 Amazon S3 Express One Zone 就合理多了。

一個檔案直接跑起大型語言模型的 llamafile

llamafile 是昨天很紅的一個專案,由 Mozilla Internet Ecosystem (MIECO) 弄出來的專案,可以使用一個檔案直接跑起大型語言模型的 HTTP server,讓你可以在瀏覽器裡面直接使用。

直接看官方的 README.md 就可以蠻簡單的跑起來,不過 Simon Willison 也有寫一篇文章介紹一下,可以看看:「llamafile is the new best way to run a LLM on your own computer」。

這邊說的「一個檔案」是指同一個檔案同時可以在 WindowsmacOSLinuxFreeBSDOpenBSD 以及 NetBSD 上面跑,而且這個檔案也把大型語言模型 (LLM) 的 model 檔案包進去,所以檔案會蠻大的,但畢竟就是方便讓人使用:

下載下來直接執行,預設就會在 port 8080 跑起來,可以直接連到 http://127.0.0.1:8080/ 連進去使用。

llamafile 用到的技術是 Cosmopolitan 專案,可以把多個平台的執行檔包在同一個檔案裡面使用。

另外用到的專案是 llama.cpp,這個蠻多人都用過了,可以很方便的用 CPU 或是 GPU 跑 LLM。

我在 Linux 上面跑剛好遇到幾個問題,都是在 README.md 上面有提到的。

第一個是 zsh 無法直接跑 llamafile (Ubuntu 22.04 內建 zsh 的是 5.8.1),這邊官方的建議是用 sh -c ./llamafile 避開:

If you use zsh and have trouble running llamafile, try saying sh -c ./llamafile. This is due to a bug that was fixed in zsh 5.9+. The same is the case for Python subprocess, old versions of Fish, etc.

另外一個對是 GPU 的支援,這邊跟你說加上 --n-gpu-layers 35 就可以用,所以一開始先用 sh -c ./llamafile --n-gpu-layers 35 試著跑:

On Linux, Nvidia cuBLAS GPU support will be compiled on the fly if (1) you have the cc compiler installed, (2) you pass the --n-gpu-layers 35 flag (or whatever value is appropriate) to enable GPU, and (3) the CUDA developer toolkit is installed on your machine and the nvcc compiler is on your path.

但可以看到沒有被 offload 到 GPU 上面:

llm_load_tensors: ggml ctx size =    0.11 MB
llm_load_tensors: using CUDA for GPU acceleration
llm_load_tensors: mem required  = 4165.47 MB
llm_load_tensors: offloading 0 repeating layers to GPU
llm_load_tensors: offloaded 0/35 layers to GPU
llm_load_tensors: VRAM used: 0.00 MB

嘗試了不同的方法,發現要跑 sh -c "./llamafile --n-gpu-layers 35",也就是把參數一起包進去,這樣就會出現對應的 offload 資訊,而且輸出也快很多:

llm_load_tensors: ggml ctx size =    0.11 MB
llm_load_tensors: using CUDA for GPU acceleration
llm_load_tensors: mem required  =   70.42 MB
llm_load_tensors: offloading 32 repeating layers to GPU
llm_load_tensors: offloading non-repeating layers to GPU
llm_load_tensors: offloaded 35/35 layers to GPU
llm_load_tensors: VRAM used: 4095.05 MB

玩了一下像是這樣:

Evernote 限縮免費版的方案

Evernote 這次算是完全限縮了免費版的方案:「Update: Evernote Free accounts will have fifty notes and one notebook」。

從 2023/12/04 開始限縮成一個 notebook 以及 50 個 note:

From December 4, the Evernote Free experience is changing. Going forward, new and existing Free users will have a maximum of fifty notes and one notebook per account.

從今年一月被併購後,二月就把整個 Evernote 團隊砍掉,就有蠻多人有悲觀的看法了,所以想轉的應該都已經轉的差不多了...

常看到的替代方案是 Notion 以及 Obsidian,反而沒看到什麼 open source 的討論?(剛剛找了一下,是有不少選擇,但名字都沒看過...)