Firefox 121 默认在 Linux 上使用 Wayland

原文 ↗ Hacker News 讨论 ↗

Firefox 121 现在在 Linux 上更偏好原生 Wayland 而不是 X11，许多人认为这象征着 Wayland 正在成为主流桌面和应用程序的默认显示系统。评论者表示，只要硬件和驱动配合，Wayland 能带来更流畅的图形、更好的安全边界和现代特性，但也强调了可访问性工具、远程控制、Nvidia 支持以及依赖 X11 开放性的长期高级用户工作流方面的严重缺口。整体语气谨慎而矛盾：有人认为 X11 已经走到尽头，破坏性变更是进步的代价；也有人担心 Wayland 的设计和碎片化会永久限制可定制性和可访问性，使其无法达到他们今天所拥有的水平。

Firefox 121 与 Wayland 默认设置

  • Firefox 多年来一直支持 Wayland；变化在于：当两者都存在时，现在优先使用原生 Wayland，而不是 XWayland。
  • 一些发行版（例如 Fedora/RHEL）已经通过打包变更，默认提供基于 Wayland 的 Firefox。
  • 如果 Wayland 不可用或不受欢迎，用户仍然可以在 X11 上运行 Firefox。

Wayland 的采用、势头与阻力

  • 许多人认为“临界质量”正在增长：GNOME 和 KDE 默认使用 Wayland，主要应用/工具包都在支持它，Wine/Cinnamon 也在转向它，基于 wlroots 的合成器也日趋成熟。
  • 也有人表示“完全没有势头”，理由包括配置困难（尤其是在非 systemd 发行版上）、功能缺失，以及围绕许多合成器的生态碎片化。
  • 对于项目延迟究竟是资源不足还是意识形态上的抵制，大家存在分歧。

X11 vs Wayland：设计、安全与兼容性

  • 支持 Wayland 的观点：更好的安全模型（没有全局键盘记录/屏幕抓取）、更合理的合成方式、更好的 HiDPI/缩放、现代协议，以及 X11 实际上已无人维护、其维护者也已将其宣告为死路。
  • 支持 X11 的观点：“开箱即用”、用于脚本/自动化的丰富 IPC、更强的网络透明性、更容易定制、广泛兼容，以及许多在 Wayland 上会失效或变得困难的工作流（xdotool、xpra、自定义 WM 等）。
  • 有人认为安全收益并不符合大多数用户的真实威胁模型，而破坏长期可用的工具是严重倒退。

可访问性问题

  • 一个大而详细的子讨论认为，Wayland 让高级可访问性和自动化（例如 Talon 语音控制）困难得多：
    • 没有统一的“Wayland server”；每个合成器都必须暴露自己的能力。
    • at-spi 只覆盖工具包级别的可访问性，而不覆盖全局窗口控制或输入操控。
    • 可访问性 API 的文档和示例很少，也难以上手。
  • 一些用户说，这最终可能会把他们从 Linux 推向 Windows 或 macOS。
  • 也有人反驳说，借助 at-spi 和工具包仍然可以实现可访问性，但承认存在缺口和缺失的协议；多人链接了开放问题列表和路线图。

硬件、驱动与性能

  • 许多人表示，Wayland 下的流畅度和延迟表现良好甚至更好（尤其是在 AMD、Steam Deck OLED、KDE/GNOME 上）。
  • Nvidia 被反复点名为主要痛点：Wayland 会话损坏或不稳定、GPU 加速失败、挂起/恢复故障，以及历史上合成器会对 Nvidia 发出警告的标志位。
  • 体验差异很大；有些人觉得 Wayland 上游戏更差（输入延迟更高），也有人觉得好得多。

主题、深色模式与桌面环境碎片化

  • 用户指出，在 GNOME/KDE 中，主题和深色模式很直接；但在像 i3 这样的纯 WM 设置中则令人困惑，需要额外工具或脚本。
  • 有人抱怨主题不一致、文本不可读、焦点指示过于细微，以及桌面环境/应用覆盖用户主题设置；也有人呼吁提供强健的按应用主题支持。

X11 的替代方案与未来

  • 有些人希望继续留在 X11，或者转向 BSD 以避免 Wayland 和 systemd，不过 BSD 也在采用 Wayland。
  • 其他人预计 XWayland 还会长期存在，但认为完整的原生 X11 已是“行走的僵尸”，只会继续衰退。