幹壞事是進步最大的原動力
Percona 家的老大 Peter Zaitsev 寫了一篇紋章抱怨 Oracle 對 MySQL 的態度：「Is Oracle Finally Killing MySQL?」。
其實大家都有感覺，2009 年 Oracle 買下 Sun (當時擁有 MySQL 的公司) 後的前幾年還有些動作，後面整個就停住了，這也導致了市場上可以看到明顯的變化，不少人都開始關注並且使用 PostgreSQL：
隔壁 MariaDB 透過 SPAC 弄的灰頭土臉後縮編不少，自己弄的 engine 還是跟 InnoDB 有一段差距，功能上也沒有比較優秀的地方...
雲端降低管理成本也是一個讓 PostgreSQL 興起的推手，如果在地端的話，MySQL 的管理工具還是成熟不少 (畢竟就是時間累積出來的)，但在雲端上面就接包的好好的了...
這是 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 TO 與 RESET MASTER 這種語法都被改成新的語法了，要重新背。
整體看起來沒有太多變化？
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...
看到 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 的消息。
剛剛翻資料才看到 Oracle 對 MySQL 5.7 的支援原來只剩下半年了，預定在 2023 年十月中止：「Oracle Technology Products - Oracle Lifetime Support Policy」。
隔壁棚 Percona 包的 Percona Server for MySQL 5.7 可以從「Percona Release Lifecycle Overview」這邊查，看起來也設定一樣的時間 (2023 年十月)，但不確定會不會宣佈延長，至少提供 security fix 之類的。
一直沒注意，突然發現只剩下半年...
在 LWN 看到 VirtualBox 7.0.0 出了：「VirtualBox 7.0.0 released」，其中 Changelog 可以在「Changelog-7.0」這邊翻到。
Ubuntu 下的更新還算方便，先把 VM 都關掉，移除 virtualbox-6.1 後再裝 virtualbox-7.0，然後把 VM 開起來看看有沒有什麼問題。
在 Changelog 裡面看到這個，這些 3D support 不知道有支援到什麼程度：
Devices: Implemented new 3D support based on DirectX 11 (and DXVK on non Windows hosts)
我把 Enable 3D Acceleration 的選項打開後變成只能跑 1600x1200，本來 1920x1200 不能跑，所以只好又關掉...
另外是支援了 virtual TPM 可以掛進去：
Devices: Added virtual TPM 1.2 and 2.0 devices
然後以前 USB 裝置的支援是 proprietary software，現在放到 open source 版本裡面了：
Devices: The EHCI and XHCI USB controller devices are now part of the open source base package
目前用起來沒什麼大問題，繼續觀察看看。
前幾天應該很多媒體都有報導了，這邊算是整理一下看到的資料。
美國最高法院公佈的全文在「18-956_d18f.pdf」這邊可以看到，算是最重要的資料。
另外很多地方也有更新，像是維基百科上面的條目「Google LLC v. Oracle America, Inc.」。
這次的案件在軟體產業也很關注，難得可以在 Hacker News 上看到 upvote 超過四千的新聞：「Google’s copying of the Java SE API was fair use [pdf] (supremecourt.gov)」，不過裡面的討論我覺得就是鄉民拿著爆米花的感覺...
第一個重要的消息當然是 6-2 認定 fair use，並且讓聯邦法院重審 (但最高法院已經把最重要的部份拍板定案了)，不過要注意的是，對於更基本的問題「API 是否有著作權」並沒有定案：
In April 2021, the Supreme Court ruled in a 6–2 decision that Google's use of the Java APIs fell within the four factors of fair use, bypassing the question on the copyrightability of the APIs. The decision reversed the Federal Circuit ruling and remanded the case for further review.
判決全文 PDF 的前面三頁多算是簡介說明這次的重點，Page 44 到 Page 62 則是反對的兩位大法官 (Clarence Thomas 與 Samuel Alito) 所提出的異議，可以看到兩位大法官批評了 copyrightability 與 fair-use analysis 的問題。
這次的結果對軟體與網路產業影響超級大，舉個例子來說，一堆公司都有推出與 Amazon S3 相容 API 的產品 (這邊是 Network-based API)。另外 Firefox 直接拿 Chromium 的 Manifest 格式來相容降低開發者開發 extension 的成本。
之後應該可以看到大家用的更爽了...
在「Migrating from Oracle to PostgreSQL: Tips and Tricks」這邊看到在討論怎麼從 Oracle 資料庫轉移到 PostgreSQL 上。
開頭介紹了 Orafce，實做了一些 Oracle 上的 function，可以使得轉移時不用改寫太多 SQL：
The "orafce" project implements of some functions from the Oracle database. The functionality was verified on Oracle 10g, and the module is useful for production work.
先記錄起來，之後如果有機會的話比較好找...
看到 Ubuntu 在安裝時支援 ZFS 的消息：「A detailed look at Ubuntu’s new experimental ZFS installer」。另外 Twitter 上也有截圖了：
Thanks to the work from @didrocks and Jean Baptiste ? a number of the #ubuntu flavours now have the experimental ZFS ? install option available in 19.10 ? pic.twitter.com/Aux8iCri4p
— Martin Wimpress (@m_wimpress) October 8, 2019
看了一下授權問題，看起來是 Ubuntu 認定這樣做不會有問題，但目前還沒被 Oracle 出手，所以也不曉得真的出手後會發生什麼事情...
算是 AWS 的 PR 稿，在老闆對雲的宣示與政治正確下本來就會陸陸續續轉過去...
這次是 Amazon 的 Consumer Business 從 Oracle 的系統換到 AWS 自己的系統：「Migration Complete – Amazon’s Consumer Business Just Turned off its Final Oracle Database」。
原先有 75 PB 的資料與 7500 個 database：
We migrated 75 petabytes of internal data stored in nearly 7,500 Oracle databases to multiple AWS database services including Amazon DynamoDB, Amazon Aurora, Amazon Relational Database Service (RDS), and Amazon Redshift.
其中一個優點是省成本，但是也投入了超過一百個團隊一起參與轉移，會需要攤多久才會打平，這點在沒有看到內部財務資料其實沒辦法判斷，而且工程資源的稀缺性也是個沒有被看到的資訊：
Cost Reduction – We reduced our database costs by over 60% on top of the heavily discounted rate we negotiated based on our scale. Customers regularly report cost savings of 90% by switching from Oracle to AWS.
More than 100 teams in Amazon’s Consumer business participated in the migration effort.
然後 latency 的下降其實也只能參考，因為轉移系統的時候也會順便改寫，有多少是因為 AWS 服務本身帶出來，在沒有內部資料看不出來：
Performance Improvements – Latency of our consumer-facing applications was reduced by 40%.
管理成本算是裡面唯一可以參考的，畢竟是搬到可延展擴充的服務：
Administrative Overhead – The switch to managed services reduced database admin overhead by 70%.
另外，沒寫的東西比較有趣，像是他們沒有選擇 Athena 而是用 Redshift，看起來像是先轉上去，其他找機會再說...