我從事與作業系統、編譯器、工具鏈和基礎設施相關的工作。這裡是我發表的文章和筆記的集合。
Wayland 是一項廣泛的誤導和資源錯配，以犧牲使用者為代價。隨著越來越多使用者從其他作業系統遷移過來，解決根本性問題的壓力變得更加顯著。經過 17 年的開發，現在是時候反思圍繞 Wayland 作為 X11 顯示協定替代品開發所做的一些宏大承諾了。
如果你不熟悉這個領域，希望這篇文章仍能作為一個關於承擔新綠地專案的工程事後檢討，讓你感興趣。具體來說：現有專案的問題是什麼？為什麼無法修復？我們希望透過新專案達成什麼目標？我們預計需要多長時間？
如果你已經熟悉 X11 和 Wayland，請隨意跳到下一部分。
對於不熟悉 Linux 的人來說，這裡快速介紹一下這個領域的術語，大致從最高層級到最低層級排列：
以上並非完整列表，但足以提供一些框架，讓你理解 X11 是大多數 Linux 環境的基礎。
X11 目前仍是 Linux 生態系統中最常見的熱門顯示伺服器。它開發於 1980 年代中期，正如遺留專案的趨勢一樣，它累積了許多功能，使得維護變得困難，開發者如是說。
因此，在 2008 年，Kristian Høgsberg 啟動了一個專案，後來被稱為 Wayland。Wayland（理論上）取代了顯示伺服器，以及部分合成器和桌面環境，提供了一個更簡單的顯示協定和參考實作。Wayland 最初的構想是只實作簡單的 Linux 桌面所需的功能。最初的實作程式碼僅有 3,000 多行。
現在是 2026 年，Wayland 的市場佔有率約為 40-50%，或根據你的來源，接近 50-60%。我認為一個花了 17 年才獲得顯著市場佔有率的產品，其發展必然存在阻礙採用的問題。將 Wayland 的開發與一個類似的音訊管理專案 PipeWire 進行比較：大約 8 年內，幾乎所有替代方案都被取代了。它自 Ubuntu 22.04 起就被採用為預設值，這大約是它首次推出後的 4 年！
以下是我從使用者角度看到的常見問題，我會盡量避免我認為大多無關緊要的技術細節，而是專注於 Wayland 推廣和設計方面的主要問題。
我使用 Linux 和其他類 Unix 系統的原因是它們賦予我對系統做任何事情的能力，包括犯錯！那麼，為什麼我的顯示伺服器會告訴我，某些我安裝並選擇執行的應用程式，為了安全起見，不允許彼此通訊？
這有多種情況：OBS 無法螢幕錄製（反而會崩潰），我無法複製貼上，而且除非所有應用程式都實作了核心協定的特定擴充功能，否則我無法看到視窗預覽。
實際的「威脅模型」令人費解，似乎並不反映使用者的需求。應用程式被阻止看到彼此的視窗，但它們無法以其他任何可能引起問題的方式進行互動嗎？
我也對「安全性」論點不以為然，因為核心參考實作的某些部分是用記憶體不安全的語言編寫的。需要明確的是，我並不是說用 C 寫的軟體不好，我特別指出，對軟體提出安全論點，然後重複前一個（40 年前）實作的決策，這看起來很糟糕。
Wayland 的幾個設計決策聲稱是為了效能。特別是，合併多個層級應該可以減少在不同元件之間移動資料時的複製次數。
然而，無論原因為何，這些效能上的提升並未實現，或者在兩個方向上都只是軼事，難以聲稱比 X11 有明顯的優勢。事實上，你可以找到顯示使用 Wayland 比 X11 慢約 40% 的例子！我相信也有類似的基準測試聲稱 Wayland 獲勝或反之（如果提供，我很樂意連結它們）。
問題是，即使 Wayland 的速度快一倍，也無法與同期硬體進步相比。最好是乾脆等待！效能提升必須更為顯著，才能成為支持 Wayland 的合理論點。事實上，在這麼長的時間後，還存在哪個更快的問題，這顯然是一種失敗。
此外，如果我無法利用這些效能提升，那麼它們就無關緊要了。例如，如果我在系統中使用最受歡迎的顯示卡供應商，我應該期望一切都能開箱即用。
我聽到的反駁之一是，這不是 Wayland 的問題，而是合成器/擴充功能/應用程式的問題。畢竟，「Wayland」不是一個軟體，它是一個簡單的協定，其他軟體選擇實作它！
當然，這在實務上的意思是，存在多個（通常不相容的）不同標準的實作。也許如果桌面作業系統的概念是全新的且未知的，這還可以，但當使用者發現拖放或螢幕共享等功能不被原生支援，並且基本上仍處於「測試版」狀態時，他們會退縮。
與其提供更好的方法來做某事，不如根本不支援常見功能，而是讓生態系統中的每個人都同意一個標準。這並不是一個令人驚豔的論點，來支持取代 X11 中已經存在且已經標準化的東西！
Wayland 存在的時間只有 17 年，而 X11 則有接近 40 年的開發歷史。事情仍在開發中，顯然會變得更好，那麼為什麼要抱怨那些不可避免會被修復的問題呢？
因為已經 17 年了，人們仍然遇到重大問題！
我對使用 KDE Plasma 時，預設顯示伺服器已變更為 Wayland 感到不愉快的驚訝。我在啟動時很快就注意到，遇到了足夠多的圖形故障，讓我意識到我正在執行 Wayland，並迅速切換回來。軼事經驗不足以說明這是一個廣泛的問題，但我的觀點是，當一般使用者在使用它 60 秒內遇到圖形問題時，也許它還沒準備好成為預設值！直到最近 6 個月，OBS 在嘗試啟動 Wayland 時才停止崩潰。我認為我並不孤單，因為即使是主要合成器的開發者在 2026 年仍無法使用 Wayland。
看似「簡單」的工具程式中有許多支援不完整或半生不熟，這令人難以置信，而且似乎是巨大的重複勞動。過去 40 年來為 X11 開發的工具鏈似乎已被完全放棄，也沒有提供替代方案。Wayland 沒有提供明顯的過渡路徑，反而引入了更多的碎片化。
擁有大量「遺留垃圾」的舊軟體已經過測試，並且錯誤早已被修復。我完全相信再有 20 年的開發，情況會更好。問題是我現在被迫進行切換。請參閱：KDE 和 Red Hat 推動 Wayland 並放棄對舊技術支援。
這篇文章最能體現開發者對試圖遷移到下一代 Linux 桌面的使用者的看法：
也許 Wayland 不適合你寶貴的使用案例。更有可能的是，它確實有效，而你只是吞下了基於可能在 7 年前就正確的假設的宣傳。無論如何，我根本不在乎你了。
我們犧牲了我們的業餘時間為你免費建造這個。如果你回頭來騷擾我們，基於一些完全毫無根據的陰謀論，那麼你就是一個該死的混蛋。
與一週後發表的文章相比，這篇文章更加諷刺，表達了對 Rust 社群的相同沮喪，就像人們對 Wayland 的感受一樣！
Drew 此後刪除了這篇文章，所以我理解如果他不再堅持這些觀點。然而，這代表了開發者對那些被迫使用未完成軟體的使用者的一種典型情緒。對開源維護者的權利主張和霸凌是不恰當的，開發者在感到被權利主張的使用者擊垮後會反擊是可以理解的。然而，從使用者的角度來看，這可能是由於被迫使用新潮事物，然後遇到一般使用者無法解決的破壞性錯誤而產生的沮喪感。
這不是原始開發者建造他們想要的東西的錯。我認為記住他們不一定選擇讓 Wayland 變得如此受歡迎，或者成為未來桌面的基礎是很重要的。請參閱下圖：
讓 Wayland 成為開發者專屬的遊樂場是可以的！盡情建造吧！但一旦實際使用者被迫使用它，就要預期他們會感到沮喪！ at this point 我認為 Wayland 是一個有趣的玩具，完全是為了安撫厭倦了處理現有遺留專案的開發者而建造的。
由於這篇文章的大部分內容都對 Wayland 的開發持壓倒性的負面態度，因此最好是盡可能多地學習，並展望「我希望能夠做什麼」。視窗技術絕對沒有「完成」，與其模仿其他作業系統，不如讓 Linux 能夠做到其他環境無法做到的事情，那將是極好的！
例如，能夠實作非矩形視窗、暴露上下文操作（類似 MacOS），或讓自動化或腳本化桌面環境的某些部分變得更容易，那將是令人興奮的！
很難誇大遊戲支援、新（和舊）硬體方面的進步，以及整體「潤飾」的程度。每位開發者都應該為參與其中而感到自豪！
經過 17 年，Wayland 仍未準備好迎接黃金時段。顯著的故障正在被記錄，採納率也相應緩慢。
對某些使用者來說，切換是無縫的。對其他人（包括我自己）來說，他們在遇到工作流程中斷的問題後，往往會選擇放棄。我認為現在很明顯，這種權衡不值得費力。
我的預測是，在未來 5 年內，以下情況將會成真：
2030 年見，Linux 桌面年。
包含一些本文引用的連結以及一些額外閱讀材料。
在放棄 X11 之前請三思。Wayland 會破壞一切！
Wayland 在核心上存在缺陷，社群需要談談
不受歡迎的觀點：Linux 世界在 Wayland/GTK4 到來之前感覺很穩定
我厭倦了這種反 Wayland 的胡說八道（已刪除）
快速移動並打破事物作為道德必然（已刪除）
我終於可以在 2026 年開始使用 Wayland 了嗎？
Wayland 終於取得進展：為什麼 2025 年是桌面 Linux 遷移年
Wayland 的真實採用率是多少
X 的簡化歷史 Hector Martin