一个 Flake 统治所有：Nix 统一包管理方案
Farid Zakaria 做了一个叫 omniflake 的 Nix flake，把一万两千多个 Nix flake 打包进一个输入，用户只需加一个 flake 就能按需取用。 核心技巧是绕过 Nix 的 inputs 机制，用 JSONL 索引表存所有 flake 的 pin 信息，需要时才懒加载。过程中还发现并修复了 Nix 锁文件生成时的二次复杂度 bug（已提交 PR #16387），4000 个输入时提速约 21 倍。
评论
点赞
收藏可查询的可执行文件：让程序成为 SQLite 数据库
把可执行文件做成 SQLite 数据库，程序运行时可以直接读写自身状态，代码和数据合并在一个文件里。作者用 self-httpd 做了个演示——一个单文件 Web 服务器，包含程序、网页、路由和访客日志，所有状态都在同一个 SQLite 文件里通过事务更新。 部署时只需 scp 一个文件，编辑运行中的网站无需重启。
可执行文件其实是一个 SQLite 数据库
Farid Zakaria 做了一个叫 SELF 的原型，把可执行文件直接变成 SQLite 数据库——chmod +x 后能跑，也能用 sqlite3 直接查询。他把 ELF 格式重新解读为"一个拒绝承认自己是数据库的数据库"，指出 ELF 的手动实现了很多数据库原语（字符串驻留、哈希索引、甚至布隆过滤器）。
三种把 SQLite 塞进 Nix 的方法
<p>核心去除 Nix API 和 CLI 后，是一个索引。这是一张来自的地图<code>(attribute, version)</code>到以 JSON 文件形式发布的版本。<br><br></p><pre><code>$ ls -lh index/ -rw-r--r--. 1 fmzakari fmzakari 7.5M Aug 19 13:57 history.json -rw-r--r--. 1 fmzakari fmzakari 5.3M Aug 19 13:57 versions.json </code></pre><p>截至,<code>versions.json</code>为5.3 MiB，且<code>history.json</code>是7.5MiB，涵盖305,492个封装版本，涵盖31,904个封装和1,534个版本。</p><p>Nix API 加载 JSON 文件时是懒惰的，并且通过以下方式读取<code>builtins.fromJSON</code>:</p><pre><code>index = builtins.fromJSON (builtins.readFile ./index/versions.json); </code></pre><p>我希望用更多信息丰富数据，但这会带来代价：数据越多，问题越多。</p><p>该项目的目标是尽量减少下载的 Nixpkg 数量。如果我们仅仅用大 JSON 替换取巨型 Nixpkg，那就不是明显的胜利。</p><p>目前我们必须谨慎选择JSON文件中存储的内容，并思考巧妙的编码方案，使数据更小更紧凑。</p><p>如果我们不被限制在尼克斯<code>builtins</code>我们会利…</p> 
nixpkgs-multiverse：用最少的 Nixpkgs 修订满足所有 pinned 包
Farid Zakaria 开发的 nixpkgs-multiverse 工具可将多个 pinned 包合并到最少数量的 Nixpkgs 修订版本中，实测 30 个包从 30 个修订降至 10 个。 算法本质是区间覆盖问题，按结束时间排序后贪心选择，复杂度 O(n log n)。作者最初误判为 NP-Complete 的 SAT 问题，后发现版本在 Nixpkgs 历史中是连续区间，实际可多项式时间求解最优解。 若版本存在空洞（被删除后重新引入），问题会退化为 NP-Complete。
DEFCON34 回顾：Nix 社区的两年之约
DEFCON34 上 Nix 社区第二次参展，演讲视频已上线。三个演讲主题：用 $ORIGIN 和 eBPF 方案解决 Nix store 路径不可重定位问题；将 Guix 包转换为 Nix derivation 让 Nix 能构建 Guix 专属的 source-bootstrapped JDK；以及一个争议性观点——Nix 社区为追求社会舒适和广泛接受度而牺牲了技术野心。
nixpkgs-multiverse 快速模式：零评估获取任意历史包版本
nixpkgs-multiverse 推出 fast 模式，无需下载和评估整个 Nixpkgs 仓库即可直接获取历史包版本的 store path。核心技巧是 tomberek 的 mkFakeDerivation——通过 builtins.appendContext 给字符串附加 context，绕过 --impure 限制，实现纯评估路径。 普查显示 上 271,187 个历史路径全部存活，共 14.8 TB。同时有 mvs 命令行工具和 footgun 警告（fake derivation 无 drvPath，override 需用.eval）。
nixpkgs-multiverse：把整个 Nixpkgs 历史版本库装进一个 Flake
Farid Zakaria 发布 nixpkgs-multiverse，一个 Flake 输入提供 Nixpkgs 历史上全部 31,783 个包、304,484 个版本对，来自 1,537 个修订。 对比其他发行版只给一个版本快照，nixpkgs-multiverse 可并行安装 246 个不同 CPython 版本。已解决 长期痛点：开发者无需为每个工具单独 pin nixpkgs 版本。 另含 daysBehind 冷却窗口和 provenance 追溯两个实用功能。
Nixpkgs-multiverse: every version that ever existed
Enter the Nixpkgs multiverse. All the versions that ever existed, all in one place. I bumped the nixpkgs release for my NixOS configuration to refresh many of my packages and found that a package I de...
用 Nix 惰性求值玩超级马里奥：每个游戏帧都是独立构建产物
用 Nix 的惰性求值特性把 Super Mario Bros. 3 的按键序列变成可复现的构建依赖，每个帧都是独立 derivation，共享 store 路径。 实测 2 万次按键评估耗时约 14 秒，构建每帧约 1.27 秒；Linux argv 限制单次最多传 21845 个按键，超出需从文件读取。 项目开源在 fzakaria/nes-nix，ROM 作为 flake input 可替换任意游戏。 核心洞察：属性路径本质是程序而非目录坐标，Nix store 可作为可重现状态机的持久化层。
在 Bazel 中用 357 字节种子构建完整 C++ 工具链
Farid Zakaria 用 LLM 辅助完成了从 357 字节种子自举的 Bazel C++ 工具链，无补丁编译 Abseil 和 GoogleTest，236 个测试全通过。 工具链含审计机制，用 Bazel aspects 验证每个构建动作只执行仓库内生成的程序，排除对外部二进制依赖。
尼克斯沙盒是一个隐藏的输入。
<p>Nix的魅力在于它极其务实地实现了“可重复性”，这个词其实有点过于繁琐。Nix 的默认模型是即<em>输入定址</em>：存储路径的哈希值由<em>配方</em>（推导）产生了它，而不是<em>字节</em>那是从中诞生的。<br><br>在这种框架下，尼克斯实现了<em>重复性</em>.Nix默认情况下从未是逐点可复现的。</p><p>为了使此方法成立，推导必须是<strong>完整描述</strong>建筑。推导中缺少任何内容会导致<em>可重复性</em>打破，Nix不再“可重复”。</p><p>在我构建了一个源代码引导的OpenJDK，我们需要提供一些额外的标志：</p><pre><code>$ nix build .#openjdk \ --option filter-syscalls false \ --option sandbox-paths '' \ ... </code></pre><p><code>--option sandbox-paths</code>为沙盒安装了额外的路径。</p><p>你可以在你的机器上看到默认的沙箱路径：</p><pre><code>$ nix config show sandbox-paths | tr ' ' '\n' /bin/sh=/nix/store/zrynrzpsy2993w555ns9a734lbzfff2b-busybox-1.37.0/bin/busybox /nix/store/cdd109fhy1axl7xb5wisv3v5pd6fawdj-qemu-aarch64-binfmt-P /run/binfmt </code></pre><p>好吧，那这有什么意义？</p><p>事实证明，这些沙盒路径是<em>隐藏输入…</em></p>
Nix 终于实现 OpenJDK 源码自举
GuixPkgs 为 Nix 实现了 OpenJDK 的源码自举，从 357 字节 C++ 程序开始历经 19 次 JDK 构建最终得到 OpenJDK 25。对比 Nixpkgs 依赖 temurin-bin 预编译二进制包的方式，Guix 方案完整展示了自举链条：jikes → GNU Classpath → JamVM → Ant/ecj → IcedTea 7/8 → OpenJDK 9→25。 实测验证了 javac 与运行环境均可用，并量化了自举带来的额外依赖节点数（876 vs 2），揭示了 Rust 等意外依赖的出现。这是 reproducible builds 领域的重要工程实践。 
Guix by Nix
I have been working more on GuixPkgs in preparation for a talk at for DEFCON34. At the end of my previous GuixPkgs post I left a teaser: We can then build a NixOS machine where every package is the Gu...
平均值毫无意义。
<p>我最近尝试验证一些与以下性能相关的改进<code>lld</code>在<code>$DAYJOB</code>看到基准测试有所提升，但实际生产仪表盘却没有改善，这让人有些沮丧。</p><p>我之前有网络服务背景，习惯了查看单个时间序列仪表盘，有时超过几个百分位数，我期待看到明显变化，但数据似乎太杂乱，无法下结论。</p><p>原来有同事在评估构建速度改进时也遇到过类似问题。有很多变量会影响构建：冷缓存、增量缓存、本地缓存、远程缓存等，构建时间会因系统状态和工作负载而有很大差异。<br><br>她最终利用累积分布函数（CDF）来可视化数据，这对我来说是个启示。</p><p>这促使我探索了除了CDF之外的其他数据可视化方式，以及单张图像或统计数据往往不足以讲述全部情况。这篇文章将介绍一个<em>合成</em>展示了不同的可视化如何讲述同一数据的不同故事。<br><br>目标是说服你<em>看</em>关注你的数据，而不是用一个数字来概括。</p><p>以下内容均来自一个带有固定种子的合成数据集。完整剧本可见.它是一个单一文件，带有<code>nix-shell</code>所以只要你用，就能精确复刻每一个模型.</p><blockquote> <strong>注释</strong>我利用人工智能帮助生成本文中的数据和图表。如果这让你不舒服，抱歉。🤷</blockquote><h2>那次“让情况更糟”的推广</h2><p>设置是这样的：我们运营一个典型的网络服务，并在一周内推出了新的缓存层，希望能减少请求延迟。</p><p>该更改已完全部署，绘制延迟仪表盘<strong>意思</strong>看起来像这样：</p><p>平均延迟消失了<em>上</em>，从112毫秒提升到122毫秒。 ☹️</p><p>如果删减了SEV，我们会恢复变更并写事后分析。右？🤔</p><h2>一个数字，四层楼…</h2>
大型代码模型究竟有什么用？
作者实测发现 GCC 和 Clang 的 -mcmodel=large 无法构建超过 2GiB 的二进制文件，TLS 访问指令仍被限制为 32 位，导致大二进制编译失败。 作者通过生成 4GiB 的.bss 和.tbss 测试用例，证明 large code model 在处理普通全局变量时有效，但在 Thread Local Storage 上彻底失效。 编译器始终生成 R_X86_64_TPOFF32 指令，无法突破 32 位偏移限制。LLVM 同样存在此问题，且 lld 明确报错指出 -4GiB 超出 [-2147483648, 2147483647] 窗口。 作者质疑该模型的实用性，指出其理论目标与实际能力存在巨大鸿沟。
小型网站改版与新设计
Farid Zakaria 用 AI 辅助改造个人博客，新增 Nix 构建标识、Jekyll 图片源集插件、CSS 哈希防缓存、页面 SHA256 曲线等细节，并重新设计布局引入侧边栏。 作者主动在 LinkedIn 和 X 寻求外部设计帮助未果后自行动手，强调避免 AI 生成痕迹。技术实现聚焦前端工程优化与个性化表达，适合关注个人站点构建、Jekyll 插件开发或 Nix 部署实践的读者讨论。
Linux 内核将支持 $ORIGIN，某种程度上
Nix 作者推动 Linux 内核支持 ELF 二进制文件的 $ORIGIN 变量，实现可重定位二进制文件。通过 eBPF 和 binfmt_misc 动态选择解释器，并引入新的分发模式解决进程身份泄露问题。 这一进展对 NixOS 及类似包管理系统的可移植性有重要意义。
如何惹恼你的 Nix 朋友
Farid Zakaria 分享对 Nix 社区的长期观察与争议观点。他认为 Nix 是面向极客的工具而非大众产品，反对盲目追求大规模普及；批评社区存在排美情绪和对 AI 工具的排斥；主张 BDFL 模式优于民主决策，建议放弃 macOS 支持以聚焦 Linux，并指出单用户安装比多用户更合理。 文章充满个人经验与鲜明立场，极易引发 Nix 用户的共鸣或反驳。 
Anubis到底拦住了谁？
作者开发Linux内核补丁时遭遇邮件列表启用Anubis人机验证，发现AI能轻易破解，但人类需承担时间能耗成本。文章通过数据量化了这种“累退税”对弱势设备和无障碍访问者的伤害，指出其实际防御效果有限却牺牲了开放网络体验。
TacoSprint 2026 回顾：Nix 开发者的海滩黑客马拉松
Nix 核心开发者在墨西哥海滩封闭开发一周，取得多项实质性进展：动态链接启动优化、无需 root 的可移植 Nix 方案、基于 P2P 的远程构建系统 drv-thru、比 nixpkgs 快 20 倍的 Zen 模块系统，以及 Guix 包映射为 Nix Flake 的基础设施桥接。
GuixPkgs：将每个 Guix 包转化为 Nix Flake
作者开发 GuixPkgs，将 GNU Guix 全部包集合转换为 Nix Flake。这解决了 Nix 用户无法直接使用 Guix 庞大软件库的问题，实现了跨构建系统的包复用。 对于同时关注 Nix 和 Guix 的工程团队，这是降低迁移成本或统一构建环境的实用方案。