Nix's Sin

迁移之殇

在我使用终于能多达10+Linux发行版之后，我越来越笃信其一点，那就是系统更新是一个骗局。

当然，据我了解到，玩hyprland、niri、quickshell的那群人呢，就是一群不滚最新系统会死星人。它们对于鲁棒性和所谓“向后移植”这种概念嗤之以鼻，然后追求“最新”这种相对稳定实则可观上完全不可控的量子态，然后声称他们的项目“只”支持推荐nixOS和archlinux用户，然后把包兼容性和跨行测试丢给一群不存在的人或者痛苦的用户。难道我们要说Debian那种软件包冻结的策略就是高明的吗？这可能有点欺负人，因为Debian stable的用户基数就是很大的一群人，那确实有一大部分人跑在trixie这个分支上，然后就针对这个稳定态发布更新和打包。但是你能说archlinux的用户基数就不大吗？那么这么看来Debian的策略似乎就不是那么高明了，而是一种妥协。（但是它是凑效的）但是亲爱的开发者们似乎不在乎这一点，它们认为追新酷毙了，然后自己就在这个不稳定态去发布版本，然后默认用户也这么干。但是这群人对于项目鲁棒性绝对是不了了之的，niri的发布说明里声称它们“实现了社区里呼声非常高的blur”，然而呢，又说“不知为何blur在以下几个应用上不能正常的工作”，最后的结论为“不管了我们就这样发布了，blur很酷！不是吗”，这也是神了。对于这种鲁棒性，我对这些项目的前景全部保有一种悲观的态度。当然，Wayland的先行和探索需要这些人去帮忙，但是我的态度就是不越雷池半步，所以我选择继续守在X11了。谢谢呀。

但是物极必反是一个显而易见的道理。事实上，我们马后炮的讲，Debian那就是过渡保守，而NixOS也不至于那么开发——NixOS的stable分支和Fedora一样半年更一次，而unstable就是全滚动——实际上，很多人说，NixOS就是一个“unstable也很stable的系统”。是的，这依赖于flake。到目前我可以给出来一个结论——Nix，是一个学习成本很高的，但是却意外的能解决我很多痛点的语言/架构。

概念辨析

• Nix：一门函数式的，声明式配置的编程语言
• nix包管理器：使用nix语言运作，底层用C++编写的包管理器。上游位于nixpkg。
• NixOS：用nix语言构建和配置的发行版
• nix-flake：一项技术，可以进行手动控制（注意，重点在于手动控制）依赖和版本锁
• nix-shell：一项可以在纯用户级进行开发环境声明依赖和工具链的技术，退出开发环境之后自动的“缓存”。不影响系统级别环境。同样归属于nixpkg的上游（从那里拉包的意思）
• HomeManager：一项基于nix语言的技术，用于管理用户级软件包（不进/usr的意思）和dotfile。

辨析这些感念是非常重要的，不懂得其背后的原理只看教程跟着配置会非常懵逼。

首先这一切都是基于nix语言的，基本的语法是需要学习的——也可以不完全懂，因为现在有llm了，然后需要明白，哪些是“可选项”，哪些不是。

nix包管理器可以用于几乎任何其他的发行版，比如软件源老旧、匮乏的Debian stable。apt去管理debian已有的稳定包，而nix包管理去负责那些apt太旧（如fastfetch）或者根本没有（如yazi）的包。

NixOS是将其管理集大成的发行版。你在配置文件中声明整个系统的配置,并且优势在于，在不同的机器之间切换配置是极其方便的。在NixOS目前的状态中，有stable分支，目前是26.05（2026年5月），和Fedora一样的更新频率，但是对于软件来说是冻结的（不是完全的冻结，这点有点像Debian），还有一个全滚动的分支unstable，但是在flake的帮助下，unstable也可以是stable的。

flake不是必须启用的，但是对于”我就要这个版本“这个需求非常好用。例如：上游分支某个软件的版本出了bug（这是真事儿，出现在krita），你就想锁死flake，那么此时flake就可以派上用场了。