引子

Debian以其坚如磐石的内核稳定性和鲁棒性著称。适不适合你用？这是一个很微妙的问题。选择一个发行版，要深刻的理解其哲学和熟悉社区环境。但是最终我还是选择了Debian，主要是图省事。apt update好久不用管，release跨版本代号更新也有令人惊叹的稳定性。（红迪上有神人声称自己从Debian3堆叠式更新到13没出问题，厉害👍）但是实则凡事都要代价，如果你不理解社区那帮Creator的逻辑的话则会令你抓狂。到最后无非就是accept或者leave。总得来说，总结一下遇到的issue，顺便谈谈这个问题，还有谈谈一些应对之策。

0 How sudo?

在Debian13’trixie’还处于testing分支，书虫归于stable的时期，我就听说Debian对于sudo有诡异的处理，不过因为有这层预防针，我大概知道是wheel用户组的毛病。自己把你自己放进去就行了。

1
2
3
4
5

1      │ pakiknowledge@Ra1nSt0n3:~$ su -
   2   │ 密码： 
   3   │ root@Ra1nSt0n3:~# usermod -aG sudo pakiknowledge
   4   │ root@Ra1nSt0n3:~# exit
   5   │ logout

这对于初学者来说可能比较劝退，但是我又不是初学者，憋笑。对于初学者可能会推荐Ubuntu？but I hate Snap,所以你可以用用mint或者elementaryOS。

1 Software issue

用fastfetch举个例子。从https://packages.debian.org可以看出，testing分支和sid分支显然是最新或者是较新的版本，而stable分支的版本竟然足足落后了22个大版本。从debian.org可以清楚的查到：

Summary

The freeze for trixie will happen according to the following timeline:

• 2025-03-15 - Milestone 1 - Transition and Toolchain Freeze
• 2025-04-15 - Milestone 2 - Soft Freeze
• 2025-05-15 - Milestone 3 - Hard Freeze - for key packages and packages without autopkgtests
• 2025-07-27 - Milestone 4 - Full Freeze

而：

也有两个主要的开发仓库 不稳定版 和 测试版 ，它们在开发下一个稳定发布期间是连续更新的。最新的软件包先进入 不稳定版中（它永远使用版本代号 “Sid " ）。当满足一些标准后，例如，没有 影响发布的严重漏洞，并且依赖关系可以被 测试版 中的其它包满足等等，它们将被从 不稳定版 自动复制到 测试版 中。

这意味着，（以这个包为代表，这是很有代表性的）软件包先流入sid之后被那些“深水区用户”测测测了一轮之后再流入testing，最后定在stable。Debian13 trixie成为stable发布的时间大约是今年五月初，stable发布之后软件包又被冻死版本，这只会导致stable源里的软件版本犹如文物。但是这是有一定好处的，比如驱动这些内核级的软件包经过这一轮“人防测试”之后在stable会呈现出一种坚如磐石的稳定和鲁棒性。这甚至是优于openqa这种现代化方案的，当然不要误会，Debian他们自己也用自动化测试，但是那群Dd（Debian developer）本就是一群古板严苛的疯子，且，人去测能测出来一些自动化QA测不出来的问题。这是一个自然而然的问题，Debian发布了13个stable release，用户基数和口碑也起来了，其“人”测的硬件多样性和架构丰富度是非常可观的。（所以不会出现Yast在老架构上死活无法正确识别较旧的显卡驱动导致无法拉起安装程序的招笑问题，因为OpenQA的GEMU是测不出来这种问题的，但是Debian社区肯定是一触即发的发现这种问题然后引发邮件列表大战。当然，agama安装器也许是一种新趋势，但是这项技术在转型期，且要取代yast一些人还有意见，总之大蜥蜴现在处于一个很尴尬的位置。）这是Debian稳定的根源，但是对于fastfetch这种可有可无的散包来说就出现问题。[为何特指此包？因为如rust、nodejs这种官方源冻死的东西，你大可从nodejs官方的第三方源(对于Debian来说，这是第三方的,因为它不属于Stable。对于node来说，这是官方的，谢谢。）导入密钥然后拉最新的nodejs，亦或者从官方源拉nvm\ rustup来管理]（又，这种可有可无是对于内核级安全稳定来说的，这就是个信息显式输出小软件，但是对于每天念十万次btw i use的rice小子，他们恨不得每天启用ff的新特性然后执行十万次把自己的光污染rice发到红迪上）那就是stable用户发现这货apt找得到，但是版本怎么这么老？这种问题在这种散包上的painful度量是最大的，起码我就遇到了这个问题。我在配置中写入："color": { "title": "#bfc9c3", "output": "#bfc9c3" } 但是这个版本不支持这么写颜色参数。所以报了错。这是一个很小的问题（大不了换传统写法，亦或者干脆dd掉）但是这反映了Debian stable的一个现实困境。那么如何解决呢？

1.格盘放弃Debian

是的，你可以这么选择。确实有些人喜欢以秒为单位的给你推更新，那btw你确实该去用arch，什么？你说你出生的时候是dpkg给你接生的？那你就去用sid。但是你滚挂了或者依赖岔了那你就受着呗？更别提apt和pacman是传统拓扑求解那一个老派梯队的，该挂就去挂。dnf的SAT求解器比较先进，但是Fedora那个开发分支也是天天挂的，本质招笑，当然如果你理解了社区哲学的话这甚至不是一个问题，总的来说it’s up 2 u.

2 .backports

这显然是一坨屎。可能网络上一些不懂行的人，还有一些吸取了这些垃圾信息的LLM，会说这是Debian一个多么多么高明的向后移植的策略，说是一种规避stable源太老的高明方案。bull shit！当你兴致勃勃试图去https://packages.debian.org找一下此源给你提供了多么多么精美的软件，以为有什么新版Firefox甚至是dev、nightly或者新版ff、nodejs之类，然后你就发现这源狗屁都没有。我都不知道这货存在的意义是啥，指望这个不如强切混用sid源（我开玩笑的。抱歉。DontBreakDebian )

3 . 黑魔法

虽然nix已经沦为和rust一样的嘉豪玩物，而且社区和rust一样已经沦为德国啤酒馆一样的邪教，但是不得不说，nix-package是根治Debian这种问题的黑魔法。说它黑，确实黑，他的cache里面收了clash这种作者本人已经进去了 的这种其他distro官方源一辈子都不敢收的软件，而且它又要拖着他的函数式语言来招摇过市，但是管那么多干嘛？先接入USTC或者STU的慈善镜像源之后直接无脑框框一通nix profile install就行了，把这东西当成升格版的apt\copr\aur用就行了，爽用最新版软件。这完全是交互式的，而且这东西全是用户级的，在辩证的吸收DontBreakDebian文档之后，就可以进行狡辩，说这东西在家目录里面智慧链接（it means’ln -s’,not ’link\web link)乱拉屎，实则不会害死Dd们呕心测试和打造的底层。

另：

1
2
3
4
5
6

>apt search  nix-setup-systemd
nix-bin/stable,now 2.26.3+dfsg-1 amd64 [已安装]
  Purely functional package manager (binaries)

nix-setup-systemd/stable,now 2.26.3+dfsg-1 all [已安装]
  Purely functional package manager (systemd setup)

所以放心啦，这两个包都进官方源了，证明那群老古板也是支持这么做的。（Debian官方源准入多难，已经人尽皆知）所以nix安装是一种安全的，总得来说易用的方案。并且如果你愿意学一学那种函数语言，你用nix装的包可以复现到其他发行版上。（当然我没有那么干，我优先交给了apt，实在没有我才让nix上，这是更安全的。但是你可以选择只有底层包交给apt，其他一律用nix，然后获得一个随时随地搬迁的用户级软件库，但是这样首先对磁盘占用更高，而且更危险，我也就没有那么干。退一万步说，都上Debian了还想着迁移，你这是对`Dd们的不信任，它可是坚如磐石的啊。）

但是这时候如果有嘉豪，特别是Wayland兴起之后试图通过这东西来拉底层的东西，比如niri，那就会出很大的问题。首先这就是一个矛盾，nix全部载入用户级的，而niri作为一个合成器，本质上和Wayland底层接口交互的东西，如果适用了nix那套“半自动”链接逻辑，大概率是拉不起来的。这根本问题在于这不是nix的标准用法，你的底层归apt管，在需要sudo进去的/usr/bin里，用用户级的东西去接入，是大错特错的。（当然我也查过，大概率你要强行拉niri起来的话要么tty自己拉，要么自己写session文件导进你自己的显示管理器里）所以说最大的安全是用户自己心里有底。事实上，Debian stable已经最大化的帮你兜底了（包括stable分支用LTS内核和freeze软件包version），但是如果你不清楚你在干嘛的话，依旧会搞坏你的系统。最大的底层安全永远来自于一个谨慎的用户。

3 . 第三类接触

软件没有？手动build。哦对了，那你不如用gentoo去，嘻嘻。这样也不安全，起码nix的包有nix-package管着，你手动build野蛮生长，nix管不了，apt更管不了，自然和nix的动态依赖链接和apt的拓扑求解无缘（然而更恐怖的是，apt并不“知情”，所以在apt自动执行事物的时候可能就不知不觉害死了你的系统了。so，DontBreakDebian。）

2 开发链的问题

事实上，这里本来有一大串问题要写，但是我想到了一种解决方案。在Debian下进行rust开发的时候（呃呃呃呃）那个狗屎编译器又吐出一堆错误，然后我研究了那个又臭又长的报错，结果是缺依赖。来自亲爱的（操蛋的）pkg-config、libssl-dev、libsensors-dev。这说明Debian的最小化安装逻辑已经病态到一个程度了（我们要进行狡辩，@Void Linux，他们的开发者认为打包进多语言字体是一种臃肿，傻逼。）（我们进行第二次狡辩，Void在官方源收录了Sarasa字体，这个字体我和爱用，😁）但是这个问题，事实上可以通过nix shell解决，这说明nix带来的对Debian stable的“补漏”作用还是很大的。所以我这里写了一堆骂人的话之后删了，因为我的实现方式错了（而不是无法实现。譬如，plasma login无法用于runit，这才是死路一条该骂的。当然，plm还是不如sddm的，至少在我看来。）

2026-06-11 22:40:06 暂时先写到这。以后吃了什么新的屎再来继续更。

附录

为何apt和pacman一样都是传统拓扑求解，apt的表现比pacman好呢？因为Debian stable源里面的软件包已经被那群疯子Dd们测的滴水不漏了。所以从源头上，apt需要处理的’负担’更小，如果你还是一个谨慎的用户的话，这种严苛的源加上智慧的人把我们的apt捧成通天代了！（啊帕次啊帕次）对于aur这种依赖乱来，也不知道是哪个时代的人传的PKGBUILD来说，pacman自然是无力处理那种依赖地狱的。arch那种依赖乱炖就算给他上了SAT求解器都救不了的，唯一一种可能是接入ai大模型让ai去判断，可能吧，我乱说的。这就像你要找净水器，但是水源已经是干净的，净水器没有必要一，亦或者是核废水，净水器显得可有可无。这又是社区开发哲学的问题了，在此按下不表，以后会讨论的。