Wayland 真的毁掉一切了吗？
有些人已经看过了这篇 Probonopd 批评 Wayland 的略有名气的文章。
Wayland X11
45.78.50.167
&gt; 嗯，除了 Fedora，所以如果你确实无法适应，那就不要用 Fedora ?<br />
<br />
好的，我用Arch Linux。<br />
<br />
作为Linux下的板绘画师，X11仍然是刚需。目前大厂Wacom似乎没有提供Wayland的适配，目前的开源驱动基于Xinput开发。更别提绘王等国产厂商了（绘王只有闭源驱动，对Linux平台也不积极适配，我猜他们多半认为“应该没有画师用Linux吧”）。<br />
<br />
加之，开源绘画工具的王牌Krita也还不支持Wayland，只能用XWayland来转换。<br />
<br />
（对了，相比Fedora，我更习惯Arch。）
来自美国的 Chrome Mobile 120.0|Android 10 用户
2023-12-29T16:26:49.000
116.22.19.2
既然这些人批评Wayland，他们为什么不去维护Xorg并修复漏洞？Xorg被发行版弃用就是因为没人维护，只知道指责不能解决问题。
来自广东广州的 Chrome Mobile 119.0|Android 10 用户
2023-12-29T16:49:41.000
38.94.111.134
之前我用wayland最头疼的两点就是输入法和hidpi。现在fcitx5输入法已经支持wayland了。hidpi的话主要是xwayland会变糊：gnome只可以做到在整数倍缩放下不糊，sway/wlroots任何倍数都会糊，只有kde可以在任何倍数缩放下都不糊。所以现在非整数倍（96dpi的非整数倍）分辨率的屏幕用wayland只有kde比较令人满意。
来自美国的 Firefox 121.0|GNU/Linux 用户
2023-12-29T21:23:08.000
101.71.196.223
批评不代表反对，我觉得Linux桌面不好不意味着我要去用Windows。Wayland拒绝支持很多在X11常见的功能，指责不一定能解决问题，但人们不能不知道指责
来自浙江杭州的 Chrome 120.0|GNU/Linux 用户
2023-12-29T23:43:28.000
101.71.196.223
这篇文章的论点和结论也大多是站不住脚的。<br />
你说“Wayland不是为了取代X11而设计的”，但是wayland.freedesktop.org第一行就写着&quot;Wayland 是 X11 窗口系统协议和架构的替代品&quot;。有了这个共识，你举的Photoshop的例子就不能说明任何问题，没有人指望一个专门为Windows开发的程序能直接在Linux上运行，但为X11开发的图形应用（几乎所有Unix/Linux图形应用）人们肯定希望它能直接运行在Wayland上，并且没有功能缺失。你不能变相强迫所有Unix/Linux gui开发者重写他们的程序。<br />
后面关于平台的讨论也没有说服力。你把Linux图形界面的分裂归咎于
来自浙江杭州的 Chrome 120.0|GNU/Linux 用户
2023-12-29T23:44:46.000
101.71.196.223
后面关于平台的讨论也没有说服力。你把Linux图形界面的分裂归咎于GKT和QT的产生，而他们产生的原因是X11提供的api不好用。事实上UI工具包和窗口系统完全是两个层级的东西，上层封装软件总是自然的产生，即使先出现的是Wayland，同样会有GKT和QT，也没见哪个Wayland程序是直接基于Wayland写的。再者，关于大平台还是小平台在Linux界一直是个见仁见智的问题，有人抱怨碎片化，有人追求多选择和可配置性，我不确定哪种是对的，但我不会说“我认为这些东西就是平台，所有应用都应该围绕它们构建”。
来自浙江杭州的 Chrome 120.0|GNU/Linux 用户
2023-12-29T23:46:49.000
101.71.196.223
最后，如果你认为Probonopd说的不对，请逐条反驳原文论点，而不是说“开发者圈子里有人对此一笑置之，乃至嘲笑”、”至少看起来有几分道理“。Probonopd列举了很多Wayland导致的问题，都是真实的用户场景，我没有看到本文对任何一条做出解释，只有不断强调Wayland有多“现代”。Probonopd的文章也并非坚守X11，只是说明了Wayland的现状，并且单独建个仓库补充Wayland缺失的东西，为的是X11应用到Wayland的平滑过度。这实际上反映了Wayland开发者的傲慢，他们不愿意听取外界意见，也不在乎gui开发者，他们只关心平台，而这个平台的推动者是
来自浙江杭州的 Chrome 120.0|GNU/Linux 用户
2023-12-29T23:48:15.000
101.71.196.223
这实际上反映了Wayland开发者的傲慢，他们不愿意听取外界意见，也不在乎gui开发者，他们只关心平台，而这个平台的推动者是当前处于开源舆论浪尖的红帽。
来自浙江杭州的 Chrome 120.0|GNU/Linux 用户
2023-12-29T23:49:35.000
58.47.153.40
&quot;with the aim to be easier to develop, extend, and maintain.&quot;<br />
“以实现更易于开发、扩展和维护为目标（的替代）。”<br />
这也是第一句的内容。<br />
断章取义了吧。<br />
<br />
显然，wayland它不是个照搬X11“能力”的替代品，不然还不如叫“移植”算了。<br />
就像从一个旧的内核编程语言转向Rust，因为代码不单追求实现，也追求安全和效率。<br />
破旧立新不是短时间的事情，短时间内看或许是“破坏和混乱”，长远能实现焕然一新却是科学发展观的必然追求。
来自湖南益阳的 Firefox 115.0|GNU/Linux 用户
2023-12-30T00:16:11.000
116.22.19.2
emmm，如果Xorg仍然在维护，也许不会有这篇文章，因为他们还有别的选择。前几年看到有个whonix开发者在他的博客称&quot;X11充满了漏洞&quot;，甚至因此认为&quot;Linux的安全性不如Windows&quot;。
来自广东广州的 Chrome Mobile 119.0|Android 10 用户
2023-12-31T08:13:05.000
175.2.68.241
捕捉一只钛山
来自湖南娄底的 Chrome Mobile 99.0|Android 12 用户
2023-12-31T13:57:15.000
39.144.67.59
我是钛山大佬的粉丝啦
来自39.144.67.59的 Chrome Mobile 120.0|Android 10 用户
2023-12-31T14:41:05.000
39.144.67.59
我是钛山大佬的粉丝啦
来自39.144.67.59的 Chrome Mobile 120.0|Android 10 用户
2023-12-31T14:41:07.000
118.239.12.99
你的说话风格和软件选择和他一模一样
来自湖南常德的 Chrome Mobile 90.0|Android 11 用户
2023-12-31T22:42:00.000
113.249.225.188
总觉得Wayland有点走营销的路子，实际并没有那么好。没有xorg稳定，没有xorg功能丰富，性能也不如xorg。X11协议真如Wayland宣传的那样out了吗？总感觉不是。随着硬件性能的提升，Wayland要尝试解决的问题似乎已经越来越微不足道，所以其功能和稳定性缺陷反而凸现。
来自重庆的 Chrome Mobile 108.0|Android 13 用户
2024-01-23T08:35:30.000
111.10.230.3
Wayland着眼于当下，更准确地说是compiz很火的那个年代，可迟迟拿不出像样的东西。X11虽然70年代就有了，哪怕和Win32、Aqua比，也是着眼于未来，所以一直被唾弃。但随着时间的推移，最后Wayland会成为X11的一种方言。
来自重庆的 Chrome 120.0|Windows 10 用户
2024-01-23T09:20:14.000
有些人已经看过了这篇 Probonopd 批评 Wayland 的略有名气的文章。
![](/data/attachment/album/202312/29/145333us6izt3xtvul3lu7.jpg)


“[Wayland 毁掉一切！](/article-16520-1.html)”有些人已经看过了这篇 Probonopd 批评 Wayland 的略有名气的文章。Probonopd 是 AppImage 开发者的核心者之一，他批评 Wayland 并非 X11 的直接替代品。他在 GitHub 上创建了一个 [新的仓库](https://github.com/probonopd/wayland-x11-compat-protocols/)，再次吸引了公众的目光，他希望为目前 Wayland 原生应用无法使用的功能创建协议。而这些功能是 Wayland 标准协议有意缺失的，但缺乏标准化意味着它们无法成为应用开发者可信赖的平台组成部分。


尽管开发者圈子里有人对此一笑置之，乃至嘲笑，但对于普通人来说，“Wayland 毁掉一切！”这句指责可能戳中要害，或者至少看起来有几分道理。因为从某种角度，Probonopd 是对的：Wayland 确实破坏了所有直接依赖 X11 功能的事物！


只是这种角度是错误的。


试想，如果我说：“Linux 让 Photoshop 无法工作，你还是应该坚持使用 Windows！”你该如何回应呢？你可能会说：“等等，问题的关键是 Photoshop 不支持 Linux！”你说得对，这是一个微妙且重要的区别，它将责任放在了正确的位置。因为即使是 Linux，也无法“不破坏” Photoshop；相反，Adobe 需要为其产品进行移植，只不过他们还没有做罢了。


对于 X11 和 Wayland，情况也同样适用。Wayland 并不是为了取代 X11 而设计的，就像 Linux 不是为了取代 Windows 而设计的一样。当我们从一个操作系统转到另一个时，有必要调整我们的期望，认清可能需要的改变。


尽管 Wayland 并非设计为 X11 的直接替代品，但它最终肯定会取代 X11。但这意味着它从一开始就打算比 X11 做得更少，而这是正确的。


### X11 是个糟糕的平台


在那些古老的日子里，X11 是个完整的开发平台。以 X11 为目标的应用程序可以使用 X11，通过内建的小部件工具包来进行 UI 绘制；借助自带的打印服务器打印文件；进行屏幕录屏；设定全局快捷键等等。这一切都远在我接触技术之前，但我感觉到，X11 要么是在最初就被设定为面向应用开发者的开发平台，要么在早期阶段迅速演变成了这样一个平台。


然而，情况并没有如预期那样发展。即使是以当时的标准而言，其内置的 UI 工具包看起来也很丑陋。那些请求同一资源的应用可能会互相冲突，破坏彼此的功能，除非卸载其中一个应用程序，否则根本无法修复。像打印这样的特性渐渐没落，因为将这样的功能放在窗口管理器里就是个错误，而后续的维护者也缺少必要的专业知识或兴趣去维护它。诸如此类，不一而足。


像 Qt 和 GTK 这样的 UI 工具包迅速崛起，以更适合用户和便于应用开发者定位的方式，接管了大多数此类应用平台程序的中间件职能。我们这里说的是九十年代中期，那已是相当久远的时代了。


*（当然，这样说可能有些不公平；人们抱怨 Wayland 缺少的其实并不是打印服务器。实际上，更多的是关于应用能否设置自定义窗口图标，以及移动自身的窗口。这些都是非常困难的情况；Wayland 上没有这些功能，理由就是这些功能在 X11 中被滥用，导致了难以解决的问题。要将这些功能移植到 Wayland 并非易事，涉及很多的权衡决定。）*


### Linux 并非一个平台


然而，UI 工具包的兴起无疑导致了应用程序的格局变得支离破碎。现在，FOSS 应用程序开发者不再为一个目标（X11）进行开发，而是为 Qt、GTK 或其他工具进行开发，从而我们看到了了大量的“KDE 应用” 和 “GNOME 应用”。是的，这些应用可能在其他平台里也能运行，但很明显，它们是在哪个平台和工具包上开发的，在哪个平台和工具包上运行效果最好。在其他平台运行时，它们可能看起来感觉很奇怪，或者某些功能可能不好用或根本无法使用。


这就是我们今天的现状。没有人会专门去编写一个 “X11 应用”；他们的应用可能会采用 X11 的某些特性，但这只是因为没有更好的替代方案，而实际上，在应用的 99.9% 的功能实现中，他们会选择 Qt、GTK、KDE Frameworks 或者其他相似工具。


这给我们带来了一个潜在的棘手问题： Linux 也不是一个真正的平台，在成为一个平台方面它并不比 X11 更成功。因为几乎没人会专门编写一个“Linux 应用”；直接调用原始的 Linux 内核系统通常是没必要的，因为无论你使用的是什么 UI 工具包，都会封装这些功能，并且将其抽象到工具包所支持的所有各种平台上。这样一来，工具包就能确保这些功能在 Linux 平台也都能顺利工作。


### 真正的平台


那么，对于跨桌面的互操作性而言，所有希望都已经破灭了吗？不，实际上现在的前景比以往任何时候都要美好！因为如今事实上出现了一个新兴的平台；如果你需要，它可以将各种应用工具包都抽象化。我说的是 Portals、PipeWire，以及 Wayland 协议。


Probonopd 认为这些都是附加组件，不应该在系统上运行，但我认为他的这种观点并不站得住脚。提供全面功能的单体窗口服务器模式在几十年前就被证明是失败的。取而代之的是库和 API，每个 FOSS 开发者都可以合理预期在现代系统运行这些。


门户系统提供了一种标准化的方法，用于展示平台原生的打开或保存对话框、发送通知、以其他应用打开文档、打印文档、拍摄截图、录制屏幕、处理拖放操作、查看用户当前主题是亮色还是暗色，等等。在很多功能的实现上，门户系统都倚赖于 PipeWire，因此你可以预期 PipeWire 也会被安装。同时，你也可以期待大部分 Wayland 合成器 — 尤其是两个最重要的合成器 KWin 和 Mutter — 支持几乎所有公开标准化的 Wayland 协议。


我认为这就是平台：Portals + Wayland + PipeWire。很明显，并没有一个好记的名字来囊括这一切。? 或许我们可以叫它 PW<sup> 2</sup>。不过，如果你的应用程序以这些平台为目标，那么它几乎可以在所有现代 Linux 系统上运行。并且，Qt 和 GTK 这两个大型的 FOSS 工具包都为此提供了全面的支持。所以，使用你喜欢的任何 UI 工具包都可。


### 为何是现在？


我们最近听到越来越多关于这个话题的讨论，因为这个转型正在加速发展。X11 的维护者已经宣布终止对其的维护，而 Plasma 则开始默认采用 Wayland，GNOME 也是如此。Fedora 甚至完全放弃了对 X11 的支持。


我们现在正处于这样一个阶段，那些以前从未考虑过这个问题的人开始思考，并意识到他们的特定使用场景所需的所有组件都还没有到位。可这其实是好事！他们的意见被听取了，变化就有可能发生。我希望这一切能早点发生，但我们也要承认现实，我们还在路上，最近围绕远程控制、色彩管理、绘图板以及窗口布局等方面的提案和工作非常频繁。可能会有一个尴尬的阶段在等我们，直到所有需要的部分都到位。对于那些由于关键遗漏而备受困扰的人，我建议他们继续使用 X11，直至问题解决。没人会去阻止你（嗯，除了 Fedora，所以如果你确实无法适应，那就不要用 Fedora ?）。探索新事物应该是充满乐趣的，如果不是这样，那就转换一个角度再尝试吧。


### 结语


在这个语境下，“毁掉一切”或许可以更准确地表达为“还没完全移植所有事物”。这种移植是必要的，因为 Wayland 设计的目标聚焦于未来，而未来并不完全兼容我们过去所做的一切，因为事实证明，其中很多东西已经没有意义了。对于那些有意义的东西，我们已经提供了一个兼容层（XWayland），同时，任何需要深度系统集成的部分，一般都有一个解决的路径（如 Portal、Wayland 协议以及 PipeWire）或者正在积极的研发中。整个世界，都在发生变化！


*（题图：DA/d5a50347-47e0-472f-833b-58203196a743）*




---


via: <https://pointieststick.com/2023/12/26/does-wayland-really-break-everything/>


作者：[Nate Graham](https://pointieststick.com/contact/) 译者：[ChatGPT](https://linux.cn/lctt/ChatGPT) 校对：[wxy](https://github.com/wxy)

