一个反直觉的观察：生信行业早就把软件分发交给了 conda 和容器，但把基底发行版的选择留给了每一台工作站的主人。 你可以在 Docker 里跑任何版本的软件，却逃不掉宿主内核、GLIBC 和显卡驱动三方之间的耦合。真正的争论往往不在”哪个软件源全”，而在”这台机器用什么更新哲学”。
先把问题框对：谁在用这些机器#
谈 Ubuntu 和 Arch 之前，先明确这类机器的画像，否则讨论会失焦：
- 联网的。工作站和服务器终究要上网，拉数据、拉镜像、同步代码，暴露面是真实的。
- 非安全专家的主人。绝大多数用生信做分析的课题组，不会专门雇一个安全运维。用户的能力边界决定了系统的默认行为不能太依赖人。
- 工具链要新鲜。CUDA 支持矩阵、编译器版本、新发布的生信软件，决定了机器还能不能装新东西。
这三条放一起，问题的核心就清晰了：一台要联网、没人专职维护、又想跟上新工具的工作站，最该担心的是”补丁到不了”还是”更新会弄坏”？ 这不是非黑即白的答案，而是两种成本的对赌。
核心差异：内核级滚动#
很多人分不清”滚动发行”和”LTS 发行”的区别，常常把”Arch 不稳定”挂在嘴边。先厘清一个事实：两者的分歧不在桌面软件，而在内核更新策略。
Debian/Ubuntu LTS 的内核是”回溯补丁”模式——主线内核打了 CVE 补丁后，发行版团队把它反向移植回自己的老内核分支，再测试、再发布。这个链条决定了补丁时延以周为单位。而 Arch 的内核基本跟着上游走，几乎用的是 Linus 和各稳定维护者推的最新 stable 内核。
这个差异在数据上有多明显？看一下不同发行版对严重内核 CVE 的平均修复时延（数据基于公开的安全通告跟踪）：
| 发行版 | 内核策略 | 严重 CVE 平均修复时延 |
|---|---|---|
| Arch Linux | 全量跟随上游 | 1–3 天 |
| Fedora | 接近上游 | 3–7 天 |
| Ubuntu LTS | 仅安全回溯 + HWE | 7–14 天 |
| Debian Stable | 保守回溯 | 7–14 天 |
| RHEL | 大体积回溯集 | 7–21 天 |
举一个具体案例：OverlayFS/Dirty Pipe 那类本地提权漏洞，Arch 大约在披露后 48 小时内把带修复的内核推进官方源，Ubuntu 大约一周，而 Debian Stable 因为要回溯到自己维护的老内核树，相关公告隔了近三周才发布。对一台共享的、跑容器的工作站来说，提权漏洞多暴露两周意味着什么，不用多说。
2026 年又补了两发更近的实弹。CVE-2026-31431（Copy Fail）和 CVE-2026-43284（Dirty Frag） 都是影响面极广的内核本地提权。社区有人用自动工具逐日监控 Debian 和 Ubuntu 的修复进度：Debian 基本在漏洞公开后 1–3 天就从 security 通道给出补丁，而 Ubuntu 一度连官方补丁都还没出，甚至有 CVE 长期停留在”待评估”状态，招来”是不是要逼人买 Pro”的批评。看到这里你大概明白我为什么会在它们身上停一下：所谓 LTS 的”长期支持”，其核心承诺就是及时可靠的安全更新；如果这条承诺在关键内核 CVE 上兑现速度落后于社区发行版，LTS 的价值主张就打了折扣。
但滚动不是免费的：你得有兜底#
跟踪上游的另一面，是”把新问题和新修复一起吸收”。滚动发行会把上游的回归也滚进来：某个点版本可能引入 ext4 写回回归，某次大版本更新可能让 amdgpu 驱动行为变化——这些在使用 mainline 跟踪模式时都可能落到你机器上。这正是蒸腾出来的运维成本。
所以”滚动”成立的前提不是否认回归风险，而是有机制让回归不致命：双内核（linux + linux-lts）留退路、快照回滚、以及让 DKMS 类模块在每次内核升级后自动重建。换句话说，滚动内核要安全，靠的不是”它不会坏”，而是”坏了能快速回去，且重建依赖是自动的”。这一条我在后面会再碰到。
供应链风险分层：真正的风险面在哪里#
这里要为 Arch 说句公道话，也顺带厘清一个被反复放大的恐慌。2026 年 6 月发生了 Atomic Arch（Sonatype-2026-003775，CVSS 8.7） 攻击：攻击者通过”孤儿包接管”机制大规模认领 AUR 中无人维护的包，篡改 PKGBUILD 注入恶意 npm 依赖（atomic-lockfile、js-digest），最终影响面从 400 多个包膨胀到约 1500–1900 个，载荷是窃密器 + eBPF rootkit，专门收割浏览器密码、SSH 私钥、云凭证。再往前，2025 年 7 月还有三个伪装成浏览器补丁的 AUR 包投放了 Chaos RAT 木马。
但是请注意安全通告里反复出现的那句话：“官方仓库未受影响。” 攻击面在被认领的孤儿包（用户级第三方包）上，不在 core/extra 官方源里。这个区分极其重要：
- 第一层，官方源：有质量门禁、有构建与维护流程，被投毒的概率低到可以忽略——你觉得”Python 本体被投毒”的概率是多少？几乎为零，因为滚动的大头是这些常规开发软件。
- 第二层，AUR/用户级自定义包：没有正式审查，任何人能认领孤儿包，这才是真实风险面。Atomic Arch 和 Chaos RAT 都倒在这一层。
所以”Arch 不安全”是个过度概括。正确的说法是：滚动的安全策略，是把风险从”等厂商补丁”转移到”管好下游自定义包”——后者才是该设门禁的地方，而不是因为恐慌放弃整条路线。对用户级自定义包，可落地的动作是所有钩子只从官方源拉取、关键凭据不放在非官方构建进程能读到的位置、对重建路径做沙箱化——这套成本远低于每月给全网机器打回溯补丁。
生态侧的证据：生信需要新鲜，已经有社区在做#
顺着”工具链要新鲜”这条线，行业里已经有现成的答案在长出来：
- BioArchLinux：一个活跃的”Arch 生信社区 + 包仓库”（2022 年 BOSC 有论文介绍），截至现在维护着 3700+ 个生信包。它的存在本身就证明：滚动哲学在生信圈有真实需求。论文里的理由很直白——“跟随 Arch 的滚动哲学，始终提供最新版的开源软件，从而为生物学研究提供更准确的结果”。它甚至给每个包配上 DOI，方便用户写论文时引用。
- BioConda/BioContainers：6000+ 包的行业标准分发方式。它们把软件分发问题解决了一大半，但容器逃不开底座——宿主内核、驱动、GLIBC 的耦合永远在那儿。你不能用一个容器把三者的兼容性一起解决。
- NVIDIA 驱动的现实：显卡驱动的正确安装方式永远不该是去官网下载，而是走发行版包管理器。而这恰恰是滚动发行最大的用武之地：新内核 + 新驱动 + 新 CUDA 的组合，在滚动源里是常态，在 LTS 源里是”自己上 PPA”的额外承诺。
那到底什么时候该用 Debian/Ubuntu#
把话说绝就错了。诚实的一节：
- 该选 LTS：内网离线机（补丁时延无所谓）、团队没有自动化兜底、机器只跑固定版本流程、管理员紧缺——Debian 的”被设计成可无人值守安全运行”（独立 security 源、
unattended-upgrades）确实是为这种场景生的。 - 该选 Arch 系：联网程度高、工具链要追新、GPU 负载重、愿意用自动化把”滚动”变成”安全的默认”。
一句话判据：联网程度越高、工具链越新、越没有专职安全人员——越该让内核自动跟随上游补丁；反之留在 LTS。 前三种条件都在说明同一个方向：让补丁及时到达，比偶尔承受一次回归更划算。
收束#
回到开头那个反直觉。生信行业把软件装进了容器，却没有把”底座更新哲学”交给任何人。而在这场”两害相权”里，真正的沉没成本不是更新带来的回归，而是暴露在已知 CVE 下的时间——尤其当补丁时延以周计算、机器又是联网的。
滚动内核不会取消风险，但它把风险的开关从”厂商排期”挪回了”你的自动化”。对一台要联网、没人专职守、又想跟上 CUDA 和生信工具浪潮的工作站——这个天平，值得认真掂量。