这，看起来只是一个再日常不过的游戏画面。伴随着DLSS4的加持，尽管开着光线追踪，也保持着较高的帧率。
然而，当我将游戏切换到后台，就会发现里面暗藏玄机：这竟然是Arch Linux，而不是大家所熟知的Windows操作系统。
这也能从侧面说明：在特定硬件、驱动和兼容层组合下，Linux已经强大到连不少Windows游戏，甚至部分带反作弊/保护机制的游戏（如我所展示的鸣潮），都有机会跑起来了。
然而，观察最新的数据（StatCounter 2026年4月全球桌面统计），你会发现，桌面操作系统市场中，占大头的依然是Windows（63.6%）；如果把StatCounter分开统计的OS X和macOS合并，苹果桌面系统约为12.58%；而Linux仅为2.99%。需要注意的是，这份数据里还有19.33%的Unknown，所以它更适合观察趋势，而不是当作绝对用户数。[来源1]在游戏用户侧，Steam硬件调查2026年4月的数据里，Linux占比也只有4.52%，Windows仍有93.47%。[来源2]
这不禁让人困惑：为什么一个这么强大的操作系统，在市场上却屡屡受挫？
▶自由的代价：无序扩张下的碎片化困局
事实上，严格来说，Linux本身是一个内核；一个可直接安装和使用的"Linux系统"，通常是由Linux内核、GNU/其他用户态组件、桌面环境、包管理器和发行版自己的配置组合而成。kernel.org也提醒用户不要直接下载"内核"当作完整系统，而应选择发行版。[来源3]由于Linux及其周边生态高度开放，任何社区、公司或个人都可以基于Linux内核和开源组件构建自己的发行版。这催生了极为丰富的Linux发行版：有常见的Ubuntu、Debian，有Red Hat支持的Fedora、CentOS Stream/RHEL系，也有可自定义性非常强、非常Geek的Arch Linux、Gentoo。
由 Andreas Lundqvist (initially), Muhammad Herdiansyah (continued), Fabio Loli (continued) - http://futurist.se/gldt/ (initially), https://github.com/konimex/linuxtimeline (continued), https://github.com/FabioLolix/LinuxTimeline (continued), GFDL 1.3
看到上面这张图，各位也意识到了Linux发行版的混乱了吧。尽管说Linux发行版大同小异，但在使用体验，环境配置等关键环节，还是有很大区别。
比如说包管理器，Ubuntu/Debian使用apt，Fedora/CentOS使用yum或dnf，openSUSE/SUSE系使用zypper，而Arch Linux/Manjaro则使用pacman。不同的包管理器有不同的使用说明书，这意味着对于用户来讲，从A发行版切换到B发行版，学习成本是极大的。
就拿最简单的安装Git命令来说：
Ubuntu/Debian:
sudo apt install git
openSUSE/SUSE:
sudo zypper install git
Arch Linux/Manjaro:
sudo pacman -S git
而Ubuntu又主推snap，Fedora Workstation也较早拥抱flatpak这类跨发行版应用分发方式。虽然它们和apt、pacman这些系统级包管理器相比，更接近"应用商店/沙盒应用"的体验，但也会带来启动速度、磁盘占用、主题一致性等额外争议（尤其是snap长期被社区诟病）。这进一步加剧了不同Linux发行版使用的割裂感。
再次说到桌面环境。由于Linux（发行版）的GUI并不是和Windows一样必须要带的（并没有进内核），因此Linux发行版的GUI/桌面环境都是由各个发行版解决的。以Ubuntu为例，主线版本默认使用GNOME，但Ubuntu家族还存在Kubuntu、Xubuntu等官方风味版；如果你打开Manjaro的官网，就会发现官方"贴心"地为你准备了三种桌面选择：Xfce，Gnome，KDE Plasma。
Windows操作系统由微软研发，只有一种主流桌面体验，用户无需操心。macOS由Apple研发，也只有一种主流桌面环境，用户也无需决定自己该选什么。而到了Linux桌面发行版这里，光桌面环境"巨头"就有Gnome和KDE Plasma，且两种桌面环境的设计哲学本质上有很大区别。
GNOME更像是"少即是多"的路线。它尽量把复杂选项藏起来，把默认体验做得统一、克制、稳定：窗口顶部通常使用Header Bar，应用设计遵循同一套GNOME HIG，核心交互围绕"活动概览"、搜索、工作区和键盘快捷键展开。它希望用户少花时间管理面板、托盘、窗口按钮、主题细节，多通过概览和搜索直接进入任务。这样做的好处是体验高度一致，新手不容易被复杂设置淹没；代价是如果你想改Dock位置、恢复传统托盘、调整窗口按钮、深度修改主题，往往就需要GNOME Tweaks或扩展来补齐。换句话说，GNOME给你的不是一张空白画布，而是一套已经替你做过很多取舍的工作流。[来源4]
KDE Plasma则更接近"默认简单，但需要时足够强大"。KDE自己的HIG也明确把"Simple by default, powerful when needed"作为核心原则：默认桌面看起来很熟悉，有开始菜单、任务栏、系统托盘、窗口按钮，用户很容易按Windows式习惯上手；但只要你愿意深入，几乎每个角落都能调——全局主题、图标、窗口装饰、面板位置、快捷键、窗口规则、桌面特效、虚拟桌面行为，甚至右键菜单和小组件都能被重新组织。它尊重的是"用户已经有自己的习惯"，所以尽量把控制权交还给用户。代价也很明显：设置项更多，路径更深，新手可能还没开始用，就先被一整套可配置项吓住了。[来源5]
所以，GNOME和KDE的差异并不是"哪个好看、哪个更高级"这么简单。GNOME更像一位产品经理：它替你做决定，让系统保持克制和一致；KDE更像一间工具房：它把工具都摆出来，让你自己决定桌面应该长什么样。对于用户来说，这本来应该是一件好事，但放在Linux桌面生态里，它也意味着教程、问题排查、软件适配和使用习惯都会继续分裂。
在图形的显示上，Linux下又分出了两大阵营：X11和Wayland。这两者均是显示协议/显示系统架构，负责管理图形界面如何呈现在屏幕上。
X Window System可以追溯到20世纪80年代，X11R1则在1987年发布（X.Org文档也常概括为Version 11在1988年前后进入稳定使用）。[来源6]它的架构设计在那个年代是先进的，但放到今天却显得臃肿：客户端与服务端之间的通信模型复杂，安全隔离不符合现代桌面预期，且代码库庞大难以维护。但它最大的优势是——兼容性极好，几乎所有Linux软件都能在X11下正常运行。
Wayland则是X11的现代替代者，官方定位就是替代X11协议和架构，让显示系统更易开发、扩展和维护。[来源7]它摒弃了X11的历史包袱，采用更现代的架构。理论上，Wayland能带来更流畅的动画、更低的延迟、更好的安全隔离。然而，Wayland的问题在于生态——很多软件尚未完全适配，功能也曾长期相对不完善。比如屏幕录制、远程桌面、输入法等关键功能，在不同桌面环境下的支持程度参差不齐。
更麻烦的是，NVIDIA显卡在Wayland下的支持长期处于"能用但问题不断"的状态。这直接导致了Wayland在相当长一段时间内很难成为所有Linux桌面用户的默认选择。直到2021年NVIDIA开始支持GBM、2024年560系列开始把开放GPU内核模块作为新GPU的默认/推荐方向后，NVIDIA在Linux桌面的体验才明显改善。[来源8][来源9]但此时距离Wayland在2008年前后启动，已经过去了十多年。
▶极客的围墙：被神化的自由，与昂贵的试错成本
Linux是自由的。你可以自由地选择你自己喜欢的发行版，自己喜欢的桌面环境，在部分"极客发行版"（如Arch Linux）你甚至自由地选择安装什么软件/库。然而，对于需要高效办公/创作的人，这份"自由"不值得获取。
在Windows下安装软件，你只需要去官网下载安装包，然后双击执行，一直下一步，就可以安装。Mac下安装软件也类似，要么从App Store一键安装，要么下载dmg文件拖进应用程序文件夹。
而在Linux下，情况就复杂得多。大多数情况下，你需要使用包管理器来安装软件。如果你用的是Ubuntu，可能还要面对是用apt安装官方仓库的旧版本，还是添加PPA源获取新版本，抑或是下载deb包手动安装的选择。如果你用的是Arch Linux，部分软件还需要从AUR（Arch用户仓库）编译安装——这意味着你的电脑需要编译环境，而编译过程可能因为依赖问题而失败。
更让人头疼的是，同一个软件在不同发行版下的包名可能不一样。比如安装Python的pip包管理器，在Debian/Ubuntu下叫python3-pip，在Fedora下叫python3-pip，在Arch Linux下则直接包含在python包里。对于新手来说，这种"同名不同命"的情况足以让人抓狂。
而这仅仅是软件安装的问题。当你遇到问题时，Windows用户可以搜索到大量图文教程；macOS用户也能找到相对统一的解决方案。但Linux用户呢？你需要先确认对方用的是什么发行版、什么桌面环境、什么显示协议（X11还是Wayland），才能判断对方的解决方案是否适用于你。这份"自由"带来的代价，是数倍于Windows/macOS的时间成本和学习成本。
游戏也是类似的逻辑。现在Linux能玩大量Windows游戏，很大程度上要归功于Wine和Proton：前者负责提供Windows程序运行所需的兼容层，后者则是Valve基于Wine等组件整合出来、面向Steam游戏优化的一套方案。对于Steam库里的游戏来说，体验已经比过去好太多了，很多时候点一下"开始游戏"就能跑起来。
但这并不意味着Linux游戏体验已经和Windows一样"无感"。一旦离开Steam，或者遇到第三方启动器、国产网游、反作弊、特殊运行环境，玩家马上又会回到试错模式：该用哪个Proton版本？要不要换Proton-GE？DXVK和VKD3D有没有启用？启动参数要不要加？环境变量要不要改？游戏闪退时，是显卡驱动的问题、兼容层的问题，还是反作弊误判的问题？
《鸣潮》就是一个很典型的例子。我的个人测试是：在桌面Linux环境下运行时，需要额外添加STEAMDECK=1或SteamOS=1之类的环境变量，才能绕开ACE相关错误。类似反馈在社区里也能找到：GamingOnLinux曾记录《鸣潮》Steam版刚上线时在Linux/SteamOS/Steam Deck上无法运行，后来随着ACE更新才恢复可玩；Valve Proton的issue中也有用户报告在SteamOS或受支持设备上通过较新的Proton版本运行；Steam社区讨论里还有用户明确提到SteamOS=1 %command%可解决ACE错误，也有人指出Proton-GE会在后台设置STEAMDECK=1。[来源26][来源27][来源28]换句话说，这不是"点开即玩"的体验，而是一种需要跟着版本、兼容层和社区经验不断调整的体验。
这才是"极客的围墙"真正劝退普通玩家的地方：不是Linux完全不能玩游戏，而是当游戏不能直接运行时，用户必须临时变成半个系统调试员。对愿意折腾的人来说，这是解决问题的乐趣；但对只想下班打一局游戏的人来说，这就是迁移到Linux的成本。
▶生态的荒原：主流商业软件的缺席
随着Wine/Proton的发展，现在的Linux桌面发行版连Windows游戏都可以玩了，然而，对于一些内容创意创作者（Adobe用户）来讲，Linux仍然接近"生态的荒原"。
在创意工作上，Adobe系列软件是绝对的"权威"。然而，Adobe Creative Cloud 2026桌面应用的官方系统要求主要面向Windows与macOS，未列出Linux桌面支持。[来源10]对于Adobe公司来讲，为了约3%的普通桌面用户专门适配，在商业上未必划算。尽管有Wine/Proton的加持，面对Adobe软件下的一些私有依赖、授权机制和图形/媒体接口，也很难保证稳定生产使用。
至于DaVinci Resolve，尽管官方专门开发了Linux版本，但在官方DaVinci Resolve 20支持格式表中，Rocky Linux版本的H.264/H.265解码/编码多处标注为Studio Only，并且依赖NVIDIA GPU加速；AAC音频在Linux表格中也未提供解码/编码支持。[来源11]再加上中文输入法、发行版适配、显卡驱动等问题，这也导致了在Linux进行创意工作的门槛极高。
至于大部分玩家所关心的游戏，尽管随着Wine/Proton的发展，Linux的游戏性能已经相当强了，然而，并不是所有的游戏都可以完美在Linux下兼容。比如：你正巧是一名《崩坏：星穹铁道》玩家，当你尝试通过Wine/Proton启动该游戏时，会发现立刻闪退。Are We Anti-Cheat Yet 将其 GNU/Linux 或 Wine/Proton 兼容状态标记为 Broken，反作弊为 miHoYo Protect，并备注需要额外 workaround。[来源12]如果你是一名《三角洲行动》《无畏契约》玩家，那就更麻烦：前者Steam页面将其列为Windows PC游戏，系统要求栏写的是Windows 10 64-bit，并明确标注使用内核级反作弊ACE；这不是说它只能在Windows 10上运行，而是说明官方并没有给出Linux/SteamOS支持。后者官方PC规格页也只列Windows 10/11，并明确不支持云游戏或虚拟机。[来源13][来源14]这类反作弊与平台限制，直接导致很多玩家继续投入到尽管臃肿但兼容性极佳的Windows操作系统。
▶硬件的博弈：Linux与NVIDIA之间难以调和的死结
2012年，在芬兰的阿尔托大学，Linus Torvalds——Linux之父正在进行一场演讲后的问答环节。台下有名观众提问了一个和NVIDIA有关的问题。而当时Linus听到后直接暴怒，并在镜头前竖起了中指，说了一句"So, NVIDIA, fxxk you"[来源16]。
这个行为对于Windows用户来说，非常不理解，毕竟NVIDIA显卡除了贵，就没有任何"缺点"了。然而，作为Linux用户，NVIDIA的痛是长久以来的问题，尽管NVIDIA驱动在如今的2025-2026年已经有很大改进。究其原因，不仅仅是NVIDIA为了维护自己的"商业秘密"而筑起的护城河，更是NVIDIA与开源社区经常性的"背道而驰"。
EGLStream与GBM之争，Wayland下空缺的10年
Wayland作为现代化的显示协议，需要一个机制让应用程序与显示服务器共享图形缓冲区——简单来说，就是让画面能够正确地显示在屏幕上。
开源社区长期使用的方案叫做GBM（Generic Buffer Management），它是Mesa项目的一部分；NVIDIA自己的驱动文档也承认，多数Wayland合成器会用GBM来初始化EGLDisplay、分配桌面EGLSurface。[来源17]AMD和Intel的显卡驱动都支持GBM，各大Wayland合成器（如GNOME的Mutter、KDE的KWin）也围绕GBM路线发展。一切看起来都很顺利，直到NVIDIA站出来表示：我们不用GBM，我们有自己的方案——EGLStream。
EGLStream是NVIDIA开发的一套专有API，功能上可以替代GBM，但只能配合NVIDIA显卡驱动使用。NVIDIA的理由是GBM的API设计不够灵活，无法满足他们的需求。但在开源社区看来，这更像是一种"我有标准，你们来适配"的傲慢态度。
结果就是，Wayland合成器的开发者们陷入了两难：要么只为GBM开发，放弃NVIDIA用户；要么同时维护两套代码路径，分别支持GBM和EGLStream。GNOME选择了后者，但并非所有开发者都愿意为NVIDIA的"特立独行"买单。KDE在相当长一段时间内对NVIDIA的Wayland支持都不理想，而一些小众合成器更是直接声明"不支持NVIDIA"。
这场拉锯战持续了多年。直到2021年10月，NVIDIA 495.44 Linux驱动正式加入GBM API支持。[来源8]此后，XWayland、GNOME、KDE、wlroots等组件继续补齐适配，NVIDIA用户的Wayland体验才逐步接近"日常可用"。而此时，距离Wayland在2008年前后启动，已经过去了十多年。
这段长期空缺，让大量NVIDIA用户被迫停留在X11，或者只能接受Wayland下的各种兼容问题，无法稳定享受Wayland带来的现代化体验。而这一切的根源，很大程度上来自一家显卡厂商长期拒绝跟随开源图形栈的主流接口。
与VA-API的斗争：Chromium流媒体下的痛
VA-API（Video Acceleration API）是一个在Linux/类Unix系统上常用的开源硬件视频加速接口，通过调用显卡来实现视频的硬件加速。Chromium文档也把VA-API描述为用于访问图形硬件视频/图像处理能力的开源库和API。[来源18]AMD和Intel显卡通常走VA-API路线。然而，NVIDIA却长期不原生支持VA-API，反而自己开发并维护了VDPAU/NVDEC等路线；VDPAU本身由NVIDIA定义，用于视频解码、后处理、合成和显示。[来源19]
尽管VDPAU是开放接口，然而，一记响亮的耳光打在了脸上：对于Chromium系浏览器，Linux硬件视频加速相关文档讨论的主要路径仍是VA-API；而且Chromium文档也提醒，Linux上的VA-API并非正式保证支持。[来源18]
这意味着什么：虽然你有一个性能非常强的NVIDIA显卡，在打开B站/YouTube看视频时，由于VA-API支持的缺失，导致只能调用你的CPU来实现视频解码并呈现在你面前。对于大部分流媒体，由于画质并不是很高且在dav1d这种高性能软件解码器的加持下，性能损失并不大。而在高画质流媒体播放下，CPU负载会蹭蹭往上涨。
尽管社区也开发了基于NVDEC下的VA-API兼容层（如nvidia-vaapi-driver），但使用体验，可用性反而成为了巨大问题。
经过我测试，发现此兼容层尽管报告指出支持AV1解码，在Chromium系浏览器（如Brave）下，却无法调用GPU进行视频解码。这并不是孤例：nvidia-vaapi-driver项目本身就说明，它是专门为Firefox网页内容硬解设计的，在其他应用中未必能正常工作；Brave的GitHub issue中也有Arch Linux + Wayland + Intel/NVIDIA混合显卡环境下，Firefox可硬件加速、Brave却无法启用的反馈；另有用户反馈称，即使vainfo列出H.264、VP9、AV1等解码入口，Brave的media-internals仍会出现VaapiVideoDecoder初始化AV1失败，且nvidia-smi看不到浏览器实际调用视频解码单元。[来源20][来源21][来源22]
与此同时，我还顺便测试了其他编码。发现目前其他编码的硬件加速也出现了问题：HEVC（Main）走VA-API，结果视频根本没法播放；VP9则会退到VpxVideoDecoder（软件解码器），H.264会退到FFmpegVideoDecoder。这部分首先是我的个人测试结果，但社区里也能找到相近反馈：有CachyOS用户反馈Brave/NVIDIA环境下HEVC在更新后停止播放，并出现vaapi_video_decoder.cc里frame pool初始化失败的日志；Brave官方GitHub也有Linux下HEVC/H.265无法播放的issue；nvidia-vaapi-driver项目中还出现过"HEVC转H.264后的视频，在不开硬解或用mpv时正常，但在Chromium/Electron里画面异常"的报告。[来源23][来源24][来源25]这些反馈不一定与我的环境完全一致，但足以说明：Chromium系浏览器、VA-API、NVIDIA兼容层和具体编码格式之间的组合，确实存在版本升级后突然失效或表现不一致的风险。
通过命令行启动，也可以看到如下日志：
[385689:386431:0503/023226.715667:ERROR:media/gpu/vaapi/vaapi_video_decoder.cc:1219] failed Initialize()ing the frame pool [385689:386663:0503/023228.543819:ERROR:media/gpu/vaapi/vaapi_video_decoder.cc:1219] failed Initialize()ing the frame pool
除此之外，该兼容层只实现了视频的解码功能，却没有实现视频的编码功能（尽管浏览器几乎不做视频编码）。nvidia-vaapi-driver项目文档也明确标注：只支持硬件解码，不支持编码。[来源20]
▶自由与妥协之间的平衡：为什么我依然选择保留Windows和Arch Linux双系统
所以，Linux桌面没有成为主流，并不意味着它"不好用"。恰恰相反，它已经足够强大、足够现代，也足够适合一部分愿意折腾、重视控制权、重视系统透明度的用户。问题在于，对大多数人来说，操作系统首先不是信仰，也不是玩具，而是进入软件、游戏、硬件和服务生态的入口。
这也是我选择保留Windows和Arch Linux双系统的原因。Windows负责那些仍然离不开商业生态的场景：比如《崩坏：星穹铁道》这类受反作弊限制的游戏，比如After Effects这类没有Linux原生版本的创作软件，也包括一些硬件厂商只认真维护Windows驱动和控制软件的设备。它不一定优雅，却足够省心；它不一定自由，却能让我少在兼容性上浪费时间。
而Arch Linux则承担另一部分需求：写代码、日常浏览、运行开发环境、玩已经适配良好的游戏，以及享受一个更透明、更可控、更少被厂商默认决策打断的系统。它不是Windows的完全替代品，而是我在Windows之外保留下来的选择权。
也许这才是今天Linux桌面最真实的位置：它不是适合所有人的答案，却是一个非常重要的备选项。它让那些不满足于默认路径的人，仍然可以拥有自己的电脑，理解自己的系统，并决定自己愿意在哪里妥协，又在哪里坚持。
▶参考文献
[来源1] StatCounter Global Stats - Desktop Operating System Market Share Worldwide（2026年4月）: https://gs.statcounter.com/os-market-share/desktop/worldwide
[来源2] Steam Hardware & Software Survey（2026年4月）: https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam
[来源3] kernel.org - About Linux Kernel: https://www.kernel.org/linux.html
[来源4] GNOME Human Interface Guidelines: https://developer.gnome.org/hig/
[来源5] KDE Human Interface Guidelines - Design Vision and Principles: https://develop.kde.org/hig/introduction/vision/
[来源6] X.Org - X11R1 / X11R7.7 Release Notes: https://www.x.org/wiki/X11R1/
[来源7] Wayland 官方介绍: https://wayland.freedesktop.org/
[来源8] NVIDIA Linux Driver 495.44 Release Highlights（GBM API支持）: https://www.nvidia.com/Download/driverResults.aspx/181274/en-us
[来源9] NVIDIA - Open GPU kernel modules / R560 默认方向: https://developer.nvidia.com/blog/nvidia-transitions-fully-towards-open-source-gpu-kernel-modules/
[来源10] Adobe Creative Cloud 技术要求（2026桌面应用系统要求）: https://helpx.adobe.com/au/download-install/apps/system-requirements/creative-cloud-requirements.html
[来源11] Blackmagic Design - DaVinci Resolve 20 Supported Formats and Codecs: https://documents.blackmagicdesign.com/SupportNotes/DaVinci_Resolve_20_Supported_Codec_List.pdf
[来源12] Are We Anti-Cheat Yet? - Honkai Star Rail: https://areweanticheatyet.com/game/honkai-star-rail
[来源13] Steam - Delta Force 系统要求: https://store.steampowered.com/app/2507950/Delta_Force/
[来源14] Riot Games - VALORANT Minimum & Recommended PC Specs: https://support-valorant.riotgames.com/hc/en-us/articles/360044136134-Minimum-Recommended-PC-Specs
[来源16] Linus Torvalds对NVIDIA竖中指事件（2012年Aalto Talk）: https://www.youtube.com/watch?v=MShbP3OpASA
[来源17] NVIDIA Driver README - GBM and GBM-based Wayland Compositors: https://download.nvidia.com/XFree86/Linux-x86_64/550.142/README/gbm.html
[来源18] Chromium VA-API 文档: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/gpu/vaapi.md
[来源19] NVIDIA VDPAU 文档: https://http.download.nvidia.com/XFree86/vdpau/doxygen/html/index.html
[来源20] nvidia-vaapi-driver 项目文档: https://github.com/elFarto/nvidia-vaapi-driver
[来源26] GamingOnLinux - Wuthering Waves now Steam Deck Playable: https://www.gamingonlinux.com/2025/07/wuthering-waves-now-steam-deck-playable-and-works-on-desktop-linux-with-one-tweak/
[来源27] ValveSoftware Proton GitHub Issue - Wuthering Waves: https://github.com/ValveSoftware/Proton/issues/8569
[来源28] Steam Community - f anticheat: https://steamcommunity.com/app/3513350/discussions/0/670599487628092516/
