Ubuntu 26.04 LTS發表值得探討的爭議

發行版推薦

我本來4月初就想寫Canonical批判文，結果拖到現在Ubuntu 26.04正式版，我很抱歉:(。
但是Ubuntu 26.04這次爆的瓜夠我單獨寫一篇文章，我批判文留到下次吧。

從Ubuntu 26.04來探討Canonical的選擇性透明與執行

我想上個月底Linux圈熱門的新聞之一就是Ubuntu 26.04 LTS推出了，推出時機正好我在規劃Canonical的批評文，我想說明為什麼Canonical維護的發行版我不再推薦，但是看到Ubuntu 26.04的出現，我認為這件事得到了一個更容易讓人看到的切角，讓我稍稍說明Ubuntu 26.04暴露出哪些問題

Ubuntu 26.04 LTS最低需求增加

最新的Ubuntu 26.04 LTS在官方Docs把最低需求抬升了，大致如下：

項目需求
CPU雙核心 2GHz+
RAM6GB+
Storage25G+

官方Docs其實並沒有這樣做成表格，而是放在Requirements and compatibility的第一行字而已，而且後面接著「for a comfortable experience.」(可以更舒適的體驗)

老實說，這根本在玩文字遊戲，先不說這個需求的不合理，我們就來看看Server版的怎麼寫，從下載介面點進去後點System requirements後底下有個Detailed system requirements，他有針對cloud image和iso image兩種最低需求。
這個更懶惰，還在以24.04為基準，上次編輯日期還是今年1/24，但即使如此，也不難看出他有Minimum RAM和Suggested minimum RAM這兩個描述，前者是最低硬體需求，後者是基於要跑更多服務提供的最小建議，也就是換句話說的推薦規格。
回到這次Ubuntu Desktop 26.04 Release Note，他只說了要有6G RAM並且標注為「有更舒適的體驗」，所以更低能不能跑？真的要這麼寫為什麼不學Server一樣寫Minimum和Suggested minimum？

那既然Canonical要拿這個規格當最低需求，我們來往回比較，Ubuntu 24.04 Desktop的最低需求是CPU持平，RAM只要4GB，如果是虛擬化環境更是只要2GB，短短2年直接暴漲50%，怎麼做的？縱使GNOME很肥，但不應該增長得這麼快，而且Ubuntu的GNOME對比標準的GNOME，是有深度定製，魔改過的，如果修改完更肥，哪很顯然不是Canonical優化技術不行，就是Canonical塞了太多垃圾。

不管怎麼說，光從行文來看，Canonical不單單也有區分最低和建議配置的寫法，甚至在社群docs^註1^也有註明，連社群不只會確定義最低和推薦要求，甚至還會區分實體機和虛擬機的需求，反觀官方Docs，Ubuntu 24.04 Release Note上次編輯日是4/6，然後還翻閱不到規格需求，僅能看到26.04草草的一句話帶過最低需求並且還將最低和流暢使用混為一談，不免讓人質疑Canonical開發團隊的專業度。

橫向對比Ubuntu Server和其他發行版

為了佐證是GNOME太肥，還是Canonical太糟糕，我們來比較一下Server和其他發行版。

我們都知道Ubuntu的上游是Debian，在拿下來對比之前，我們先比較一下Ubuntu Desktop和Server自己之間的差距。

這裡用iso image為例，Ubuntu Server的最低要求是1.5G，只有Desktop最低要求的1/4，如果你拿建議最低規格，那也才3G，還是Desktop的1/2大小而已，光加個DE而已overhead(額外開銷)就有3G，這未免有點太肥？你真要跟我說GNOME很肥，那我就拿上游比較。

根據Debian 安裝手冊 3.4章^註2^，Desktop推薦RAM大小為2GB，比Ubuntu Server建議最低規格還小，但我們都知道Debian很乾淨，但你說Debian很多DE可以選所以不準？你要知道，Debian預設的DE是GNOME，即使預設是GNOME這種很肥的DE的情況下Debian還是開了2G的推薦大小，更不要說Debian with Desktop最低要求寫的是1G。

「但是Debian太乾淨了，Ubuntu桌面端真正的競爭對手是Fedora，他背後也是商業公司」，好，順應這句話，我們來分析一下。
Fedora預設也是GNOME，而且不像是Debian是什麼都給你讓你去勾，預設Workstation版本就是GNOME，要安裝KDE Plasma是要下載Fedora KDE Plasma的獨立iso的，所以Fedora主要還是以GNOME為主。
在此之上，我們就來看看官方的硬體建議，在最新Fedora 43的Docs的Hardware Overview的章節，最低系統要求是CPU一樣是雙核2GHz+，但是RAM最低要求也是2G，對比之下Ubuntu 26.04最低是6G，同為現役最新系統，這個差距還是過於懸殊，僅有1/3的要求。

而且Debian和Fedora還都是用原生GNOME，即使Fedora因為頭上是Red Hat有塞專屬於Red hat家族的套件，加一加還是比Ubuntu輕，而且還都是帶DE的情況下，最新的Fedora 43都比Ubuntu 24.04還輕，更不要說Ubuntu 26.04了，這到底是加了太多料還是魔改了太多還是兩者都有？
而且minimum的定義悄悄的從最低能跑變成舒適體驗，甚至不同文件用不同標準，這顯然是「選擇性行為」老毛病再犯，而且範圍越來越大，無論是之前的Snap，接下來會說到Kernel 7.0選擇，還是我未來其他文章要批評的GRUB肢解案。

這裡順便補充一點，Ubuntu 24.04 LTS iso大小大約4.6G，到了Ubuntu 26.04 LTS後iso大小變成6G，連iso都變得如此肥大，不予置評。

Ubuntu 26.04選用7.0 Kernel

好了，這個又是一個選擇性案例，這件事乍一看，是一個LTS發行版比Arch還激進，第一個吃螃蟹，但實則不只。

我們先來看一下Ubuntu 26.04的發行行程：

你們會看到Feature Freeze(功能凍結)對吧？這張圖只有寫粗略的時程，3/19是只是停止從Debian-unstable拉套件而已，你從Release Note那邊展開點進Release schedule後就可以看到這張圖，往下拉你可以看到更完整的時程表，這時可以先解釋FF是幹嘛的。

功能凍結是Ubuntu開發和測試時用來保證系統穩定的步驟，他會逐步鎖定套件(功能凍結)、Kernel功能(Kernel功能凍結)、Kernel(Kernel凍結)、最終凍結到最後發佈，那我們先來看看官方釋出的Feature Freeze流程：

  • Feature Freeze: 2/19
  • Kernel Feature Freeze: 3/19
  • Kernel Freeze: 4/9
  • Final Freeze: 4/16
  • Final Release: 4/23

附上圖片：

所以發行流程上，功能凍結其實可以大致切分成功能 -> Kernel -> 釋出，那為什麼是先凍結功能而不是Kernel，在官方Docs中在Kernel Feature Freeze有段Note是這樣說的：

The Kernel Feature Freeze occurs after the Feature Freeze because the Linux Kernel is typically released upstream after the Feature Freeze. Additionally, the Kernel Feature Freeze is deliberately scheduled so that the Beta images have a fully featured kernel suitable for testing.

簡單說就是有的功能或套件因為會仰賴新Kernel，所以把Kernel的凍結會放到Feature Freeze之後，既保證相容性，也保證Kernel可以得到更多修補和更新。
然後這一版的Docs在Feature Freeze有這樣一段說明：

在功能凍結（FF）期間，Ubuntu開發人員停止引入新功能、軟體包和API/ABI更改…
在某些情況下可以申請例外情況——此類例外情況必須得到Ubuntu Release Team的批准。

這次Docs明確提到ABI，當kernel重大更新時會破壞Kernel module ABI，帶來的影響是所有DKMS都要重新build，所以FF之後需要更新Kernel應當要取得整個維護團隊的同意。

與此同時，時程表中有個計劃中的和可能的破壞性的全活動紀錄，你會發現很奇怪的事情，早在距離FF還很遠的2025/10光Python、Golang相關更新都有放進來，結果Kernel的任何更新都沒放進來，我們比較一下Ubuntu 26.04的前一版：Ubuntu 25.10，在日誌中他們直接明說是Kernel 6.17，那不管是6.18還是6.19都應當是重大更新，Kernel更新帶來的ABI更改對系統絕對是「破壞性」的。

然後我們再回去看看這份討論，我們可以看到Canonical從一開始就是瞄準6.19的下一個版本，原話說甚至說了「even if the upstream kernel is still in Release Candidate (RC) status at the time of release.」——即使上游Kernel釋出時還是RC狀態。
這個決策透露了兩個問題，第一是這個決策居然會在LTS上面鎖定缺乏驗證(其他發行版沒用過)的Kernel作為LTS的kernel，就算Canonical有能力maintain，但這無疑也會給予Canonical帶來更大的維護壓力。
但是比起維護壓力，這個決策帶來更大的問題是他們甚至不惜讓LTS使用者使用預覽版Kernel，如果FF後新Kernel才推出呢？或者是Final Release時新Kernel還在預覽時直接把LTS使用者釘在預覽版Kernel嗎？

最後雖然出於大家都懂的原因，新Kernel的版本不是6.20，而是變成7.0，所以我們來看看Kernel 7.0的發行週期：rc1推出的日期是2/22，正式版的推出日期是4/12，rc1推出的時候甚至已經功能凍結之後了，然後Final Release推出的時候給他們賭對了，幾乎是在最終凍結之前壓線推出，如果在最終凍結甚至Release之後Kernel 7.0正式版才推出，我都不敢想像LTS系統居然要用好幾年的Kernel 7.0-rc7。

雖然給他們賭贏了，但我們也要來看看LTS用這麼新的Kernel有新到多麼荒謬？根據9To5Linux的報導，Arch一路到5/1才釋出包含kernel 7.0的iso，Kernel比Arch還新的LTS你見過嗎？

對比之下，我們來看看上個LTS版本，也就是24.04的狀況，Kubuntu當時因為KDE Plasma 6剛出來擔心不穩定所以在FF的時候最後收錄的是KDE Plasma 5.27，沒過多久人家Arch和openSUSE風滾草後來Wayland和HiDPI用的很開心，結果Kubuntu要等到26.04才能享受到一等Wayland體驗，除了等到了Wayland原生支持以外和Canonical的「選擇性穩定性」，我們還等到了這些東西…

更多Snap和待解CVE

沒錯，我們還等到了更多的Snap，Canonical或者有跟Canonical合作的開發工具被進一步拉到Snap裡面，與此同時，GNOME Shell和剩下的GNOME組件直到這一版本才完全Snap化，前者想把生態留在Snap，但是後者則說明自家明明在推行Snap，但直到現在才完整整合，能側面說明Snap與Ubuntu的整合直到這版才比較成熟。
與此同時，Ubuntu 26.04把Software & Updates移除，只留App Center，Software & Updates它可以用來管理.snap和.deb的套件，這樣移除也就意味著Canonical想把套件管理導向到Snap，不打算讓使用者可以管理和使用.deb包(除了擅長用指令的人)，屬於Snap的管理範圍擴大。

除此之外我們還有開發到一半的rust-coreutils，Canonical這次Coreutils用Rust重寫的版本，為了避免GNU Coreutils因為用C語言會有記憶體問題，結果官方的rust-coreutils版本才0.8，不是正式版，更扯的是GNU Coreutils沒什麼Bug爆發，反而Canonical自己請Zellic檢查後，在rust-coreutils 0.8揪出113個issues，最要命的是這個rust-coreutils還是「用一半」，因為最核心的cp、mv和rm在rust-coreutils上面有 TOCTOU race condition，所以變成現在的coreutils是GNU原生的和rust-coreutils混用的狀態，有做過LFS都知道Coreutils是Linux最核心的套件，結果LTS使用這種半成品 + 縫合怪當作最核心的Linux交互界面，這屬實說不過去。

對於「選擇性」和「以我為主」的發行版的看法

那可以看到，這樣子的Ubuntu 26.04是真的越來越強勢了，從幾年前的強推Snap開始，到現在Ubuntu-flavor因為保守所以用穩定的版本，結果Canonical本家直接用最新的Kernel，甚至新到連Arch都還沒有用上Canonical就先用了，真不敢想像可以在LTS上面看到標有rc的Kernel。

至於後面的rust-coreutils，根本就是Mir和Upstart的翻版，只是rust-coreutils只影響Ubuntu 26.04使用者，但是後面兩個Mir和Upstart是會影響整個Linux技術棧，所以後面兩個之後就慢慢消亡了，至於rust-coreutils，我只能說各位Ubuntu 26.04 LTS使用者好好加油吧。

註解

  • 註1: 編寫時文章右下角寫著Installation/SystemRequirements (上次是 inclusive-disjunction 在 2024-07-24 17:54:19 編輯的)
  • 註2: 撰寫這篇時該手冊版本為20250803+deb13u1

Reference