KDE Linux 使用体验

# KDE Linux使用体验 | AksDev 来源：https://akselmo.dev/posts/kde-linux-experiences/ *发布于2026年8月21日 (https://akselmo.dev/posts/kde-linux-experiences/) 作者* 我几乎一整年都在日常使用KDE Linux (https://linux.kde.org/)，虽然我很喜欢它，但最近正准备切回Fedora KDE (https://fedoraproject.org/kde/)。以下是我对这套系统的全面思考。 KDE Linux (https://linux.kde.org/)是KDE官方推出的新锐Linux发行版。目前它基于Arch Linux构建，但进行了大量定制修改。官网有详细介绍，简而言之：这是一个原子式/"不可变"发行版，除了安装flatpak应用外没有任何其他包管理方式*（注意：他们正在试验用Buildstream替代Arch Linux）。* 作为KDE开发者之一，我在兼顾工作与娱乐（游戏）的主机上持续运行了这套系统一年。 以下内容可能涉及较多技术细节，我会从开发者的视角切入，同时也会提及日常使用体验。 ## 优势篇 (https://akselmo.dev/posts/kde-linux-experiences/#upsides) ![我的蜥蜴拟人形象露出微笑] 对于通用计算和KDE开发来说，整体表现相当出色！ 坦白说，考虑到它目前的Alpha状态，系统运行已相当稳定。特别适合开发工作——每天都能直接获取git仓库中最新最热的代码构建版本，省去我每天手动编译的麻烦。 当然也存在一些问题：有时服务器会因故无法生成新镜像，最终可能仍需自行构建；偶尔镜像中会包含有问题的变更。不过好在遇到这类情况时，我可以直接回滚使用上一个镜像。 我特别喜欢的是systemd-sysext (https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html)工作流。Sysext允许我将自定义修改叠加在系统基础层之上。比如当系统执行`/usr/bin/konsole`时，实际运行的是我自编译的`/home/akseli/Projects/kde/usr/bin/konsole`。对系统而言，它们处于完全相同的路径。 在其他发行版中，我们通常需要通过环境变量来指定构建路径，虽然也能实现类似效果，但可能更脆弱（尤其在测试登录管理器等系统组件时）。 我的工作流程很简单： - 使用kde-builder编译应用程序或Plasma桌面组件的修改 - 通过`run0·systemd-sysext·--always-refresh=yes·refresh;`刷新sysext层（也可用`sudo`，我偏好前者因为长时间编译后弹出提示能让我及时察觉） - 变更立即在系统中生效！ - 应用可能需要重启 - 出现问题时只需清理sysext文件夹 这套方案更稳健且易于管理。KDE Linux在此方面带来了极大的开发便利，堪称测试和开发KDE Plasma组件的完美平台。 关于flatpak应用，通常都能正常运行，但偶尔会遇到典型flatpak问题：某些应用需要访问特定文件夹却因权限限制无法看到，导致你不得不关闭应用→添加权限→重新打开应用...如此反复。正确使用XDG portals (https://flatpak.github.io/xdg-desktop-portal/docs/)的应用通常表现良好，不过系统更新（即原子镜像变更）时存在一个bug：portal会遗忘已授权的文件夹路径，需要重新打开文件才能刷新路径。 游戏方面，Steam Flatpak表现非常出色，与原生包相比未发现任何差异。Bottles也运行良好。偶尔会出现游戏无法正确锁定光标等问题，但随着更多用户发现这些bug，后续更新通常会快速修复。 ## 劣势篇 (https://akselmo.dev/posts/kde-linux-experiences/#downsides) ![我的蜥蜴拟人形象露出悲伤表情] 当使用场景超出系统设计预期时，问题就会显现。 作为原子发行版，所有未预装的开发工具（如你喜欢的终端工具或文本编辑器）都需要像Windows用户那样从网络下载二进制文件到`~/·local/bin`，或使用Distrobox/Kapsule/Toolbox等容器方案。 容器工作流对我而言大多时候显得笨重。进行KDE开发时，由于系统已预装所有构建和运行工具，体验相当流畅。但当我想继续开发游戏项目（比如我的Artificial Rage (https://sr.ht/~akselmo/ArtificialRage/)）时，就必须进入distrobox容器，安装所有依赖，然后在容器内编辑和构建。每次切换项目都可能需要创建新容器，如此循环往复。 我对此并不习惯。我更倾向于所有工具直接安装在主机环境中，无需折腾容器。我的记性不好且不擅长上下文切换，经常忘记切换或创建容器。 为此我创建了一系列名为dbi (https://sr.ht/~akselmo/dbi/)的脚本工具，通过distrobox-export命令将应用符号链接到`~/·local/bin`，实现在主机中直接运行容器应用。虽然这不是理想方案，但确实解决了问题。不过运行eza (https://github.com/eza-community/eza)这类工具时会遇到性能损耗——这个能显示图标的`ls`替代品在主机直接运行时瞬间响应，通过distrobox运行却要1-2秒，频繁切换目录时这个延迟会明显影响体验。尚不清楚能否优化，速度瓶颈很可能来自容器调用环节。 这引出了更本质的问题：缺乏官方认可的包管理方案，特别是命令行工具管理。 我尝试过多种工具，但都存在各类问题： - Brew：用户体验出色，但有时会覆盖系统Python并破坏kde-builder（不确定是否已修复，我不敢尝试） - Coldbrew：体验类似Brew，但包版本有时不够准确 - Nix：对此用例过于复杂且体验糟糕——虽然能用，但每次更新应用都需记得执行垃圾回收等操作（可通过友好封装解决），但有人主张"这不是Nix的正统用法"，让我陷入既想用又怕用错的困境 最终我只能继续使用distrobox并接受性能与体验的折衷。 另一个遗憾是无法直接安装KMail和KOrganizer与数字时钟小部件联动。当点击时钟时直接显示日程事件——这看似小事，却极大提升了我的工作效率。Kontact的flatpak版本无法实现此功能，且整体存在诸多缺陷。 此外，由于我参与Union (https://invent.kde.org/plasma/union)样式引擎开发，flatpak应用暂时无法使用Union样式。这意味着我需要通过CI构建单独的KDE平台 (https://akselmo.dev/posts/flatpak-kdeplatform-ci/)，过程可能极其缓慢（尤其需要多次构建验证修改时）。某些复杂应用如KMail的构建会耗时更久。这时我格外怀念Fedora上通过`dnf`直接安装应用——由于应用与Union样式都安装在主机，能直接使用最新样式。 ## 日常使用与我的需求 (https://akselmo.dev/posts/kde-linux-experiences/#regular-use-and-my-use) 对于仅使用浏览器、玩游戏且完全不涉及终端的普通用户，KDE Linux应该能很好地满足需求（特别是当系统开始提供非每日更新的稳定版时）。目前它的定位更偏向开发工具，除非你是狂热爱好者或拥有备用设备，否则不建议作为日常系统。 但像我这样经常撰写Linux和KDE技术文章的极客，更看重系统的完全掌控权。我不介意主机上安装各种开发工具*（涉及NPM的项目例外，幸运的是我很少需要处理这类项目）*。不过原子发行版往往有自己的设计哲学——当这些设计与你的需求不符时，修改系统会非常困难（我了解ostree方案）。 因此我认为：使用场景越复杂，越需要基础系统未提供的工具时，系统会显得越笨拙。 这就是我回归Fedora KDE的原因——它赋予了我所需的完全控制权。我仍然会继续使用flatpak安装大部分应用，因为沙盒机制确实能提升系统安全性。 我强烈建议所有想体验最新KDE特性的用户，在虚拟机或备用设备上尝试KDE Linux。我的笔记本将继续使用KDE Linux——那里需求单一，我只需直接安装git最新代码而无需编译（因为笔记本编译速度实在太慢）。 这件事也让我意识到... ![我的蜥蜴拟人形象露出微笑] 所有发行版都有其优势、劣势和权衡。关键在于选择最适合你和你设备的方案。 我的主力机适合Fedora KDE，而笔记本则更适合KDE Linux。 我会持续关注KDE Linux的发展，未来或许会在主力机上再次尝试。 可能有读者会问：*"为什么是Fedora KDE？"* 在我体验过的KDE发行版中，这是最优秀的之一。Fedora KDE团队的成员都非常友善，与上游KDE社区保持着密切合作。Fedora KDE对KDE版本更新跟进极快，让我始终处于最新开发版本，大大简化了开发流程。 感谢阅读！ 附：朋友发给我的这张图让我笑出了声。