技术文章 Fzakaria Blog 2026/08/11
文章介绍 nixpkgs-multiverse 项目，它通过一个 Nix flake 输入，提供 Nixpkgs 所有历史版本中每一版软件包的每一个独立版本。因 Nix 早于 FHS 的设计允许多版本共存，multiverse 收录了 304,484 个软件包版本对，涵盖 1,537 个 Nixpkgs 修订版，远超其他发行版；文中以 CPython 为例展示 246 个可并存的版本，并配有数据可视化对比。文章还说明 multiverse 帮助解决了 devenv 中依赖固定版本的长期问题，并介绍了 daysBehind 冷却窗口和 provenance 元数据特性。方案本质是 5 MB JSON 和 200 行 Nix 代码，并无复杂技术，但概念大胆，展现了 Nix 可复现构建与版本寻址的潜力。
本文展示了一个充分利用 Nix 可复现、多版本共存特性的创新案例，通过具体数据和真实工程问题解决（devenv 包固定）证明了其长期参考价值。适合对 Nix、开发环境可复现性及依赖管理感兴趣的开发者，文中的设计思路和方法可迁移到其他需要多版本支持或环境锁定的场景。
工程实践 Fzakaria Blog 2026/08/09
文章介绍 nixpkgs-multiverse 项目，通过一个 flake 输入提供 Nixpkgs 所有历史版本的惰性访问，解决多版本依赖时需固定多个 flake 输入的性能和易用性问题。核心方法是用 revisions.json 与 versions.json 索引包版本到修订的映射，并利用 builtins.fetchTree 按需获取；数据编码仅保留每个版本的最新出现修订，将索引大小控制在 5 MB 左右。性能实验表明，相比急切获取多个 flake 输入，该方案解析开销极低且遵循按修订计费原则。项目不构建或镜像任何内容，仅是对已有 Hydra 缓存的映射层，适合需要在 Nix 生态中灵活组合不同版本包的开发或构建环境。
推荐收录，因为它展示了一个真实的工程问题（Nix flake 多版本输入的性能与可用性冲突），并给出了完整的设计方案、数据优化与性能对比，具备可迁移的工程判断和工具设计思路。对使用 Nix、关注包管理与依赖分析的读者有直接参考价值，其惰性索引与按修订计费的设计也可启发其他需要高效版本查询的系统。
工程实践 Fzakaria Blog 2026/08/06
文章探索了利用Nix语言的惰性求值特性，将属性路径转化为Super Mario Bros. 3的按键输入序列。作者通过将每次按键操作定义为独立的派生（derivation），并使每个派生依赖前一帧的快照作为输入，从而实现了游戏状态的懒加载与增量构建。Nix store实际上充当了模拟器快照历史的持久层，分支或追加操作只需计算增量部分。文章还分析了递归深度限制（默认约2400次按键）、内核命令行参数长度限制（21,845次按键）以及构建时间线性增长等实际约束，并提出了通过文件输入绕过限制的方案。该工程案例展示了Nix派生机制在游戏状态机中的创意应用，但主要用于技术演示，性能开销较大。
推荐收录，因为这不是简单的技术玩梗，而是深入展示了Nix惰性求值、派生依赖和内容寻址存储的底层机制。文章提供了细致的基准测试和限制分析，对理解Nix的运行模型和扩展能力很有启发。适合对Nix或函数式构建系统感兴趣的工程师，其将输入序列拆分为可复用的派生单元的思想可迁移到其他需要增量构建或状态机复现的场景。
工程实践 Fzakaria Blog 2026/08/01
文章介绍了一个在 Bazel 中从 357 字节的 hex0 种子自举构建的 C++ 工具链。作者受 stage0 和发行版自举过程启发，利用 LLM 协助完成了这一机械但步骤繁多的工程，最终工具链能够无补丁编译 Bazel Central Registry 中的 Abseil 和 GoogleTest，并通过 236 项测试。工具链包含审计报告，利用 Bazel aspect 验证构建图中每个动作仅执行工具链自产的程序，确保了极高的封闭性。当前方案仍需系统提供的 shell，但显著提升了 Bazel 构建的可重现性，适用于对构建可信性、可移植性有要求的 C/C++ 项目。
推荐收录，因为它将一个很有挑战性的自举工具链工程在 Bazel 体系中完整实现，并用实际测试和审计报告证明了可行性。这对于关注构建可重现性、供应链安全以及工具链定制的工程师具有直接的参考价值，文中的自举流程和封闭性验证方法可直接迁移至类似基础设施建设项目。
技术文章 Fzakaria Blog 2026/07/31
文章深入分析了Nix沙盒配置（sandbox-paths）如何成为推导的隐式输入，破坏了推导作为完整构建配方的理想。作者通过一个极简示例演示：当沙盒中不挂载/truth时，推导输出“2+2=4”；挂载包含不实内容的/truth后，输出变为“2+2=5”，但输出哈希不变，说明相同的.drv可以产生不同内容。文章进一步讨论此问题的严重性：默认sandbox-paths取决于Nix二进制的编译选项（如是否带busybox），不同机器上的“相同”Nix版本可能因隐式输入差异而产生不可重复的构建。作者还结合自己构建OpenJDK的实例，说明Guix软件包假设不存在/bin/sh而Nix默认提供，导致构建过程静默走上不同分支并生成损坏产物，该损坏产物还被无心上传至二进制缓存。文章揭示了Nix设计中的一个根本性权衡：将sandbox-paths纳入推导会破坏缓存共享，而排除则损害可重复性。其边界在于仅讨论intensional模型，content-addressed derivations或可缓解。
文章通过一个简洁可复现的例子，直观展示了Nix沙盒路径如何成为隐式输入，破坏推导的完整性和可重复性，并结合作者构建OpenJDK的真实踩坑经历，揭示了该问题在跨机器构建和二进制缓存投毒中的实际风险。适合所有关注构建可重复性和供应链安全的Nix用户、DevOps工程师阅读；其揭示的“隐式输入”原理可迁移至任何追求封闭构建的系统，提醒我们在依赖缓存时需重新审视信任假设。
工程实践 Fzakaria Blog 2026/07/30
文章记录了在Nix包管理器中实现从源代码自举构建OpenJDK的完整过程，通过移植Guix的bootstrap链（jikes、GNU Classpath、JamVM等），从零开始逐步构建出OpenJDK 7至25，脱离了对预编译二进制JDK的依赖。作者详细对比了Nixpkgs传统依赖二进制seed与GuixPkgs全源代码构建的闭包差异，量化了引导额外引入的876个推导项，并指出共享的C++工具链占据闭包主体。该工作展示了可复现构建在持久化软件供应链中的进展，同时也揭示了当前JDK自举对特定历史工具链的依赖和构建环境的复杂性。
推荐收录，因为本文不是简单的工具介绍，而是提供了真实的工程方案和可复现的构建链细节，包括从jikes到OpenJDK 25的19次完整构建过程及闭包分析。适合关注可复现构建、软件供应链安全或Nix/Guix生态的开发者，文中的自举策略和依赖分析手法可直接迁移到其他编译型语言的自举实践中。
工程实践 Fzakaria Blog 2026/07/30
文章展示了“Guix by Nix”项目，通过 guix-transfer 工具将 Guix 的软件包派生图翻译为 Nix 派生，并利用 Nix 守护进程构建了一个可启动的虚拟机镜像。该镜像以 Guix 的 Linux-libre 为内核，用户空间全部来自翻译后的 Guix 软件包，并以 GNU Shepherd 作为 init 系统，完全排除了 systemd 和 D-Bus。作者提供了自动化审计机制，验证所有可执行文件和脚本解释器均源自 Guix 输出，确保无 Nixpkgs 组件混入。文章还讨论了与 Nixpkgs 混合、构建非 systemd 系统等潜在拓展，但明确当前仅为最小演示，不适合生产环境。该案例对理解构建系统互操作、可重现系统构建和 init 系统替换具有参考价值。
推荐收录，因为它不是简单的工具使用，而是展示了将 Guix 生态翻译到 Nix 构建系统的完整工程方案，并附带了可验证的审计链。这对研究构建系统、操作系统定制或探索 Nix 作为通用构建语言的读者有直接启发，文中跨生态翻译、派生图转换和自证明验证方法均可迁移到类似项目。
技术文章 Fzakaria Blog 2026/07/27
文章以一次误导性的平均延迟指标为切入点，系统介绍了如何通过多种可视化手段正确理解性能分布数据。作者使用一个合成数据集模拟 Web 服务缓存上线场景，展示平均值、中位数、百分位数给出矛盾结论的原因，并依次通过密度图、累计分布函数（CDF）、位移函数、山脊图、热力图和联合图揭示数据呈双峰分布的实质：缓存命中导致低延迟，缓存未命中的大请求造成长尾。文章重点强调 CDF 能同时展示所有分位数的变化，尤其当两条 CDF 曲线交叉时，单一统计量无法概括整体效果。文中所有图表附有可复现的 Nix 脚本，便于读者在自己的数据上实践。该文既是一堂生动的可视化教学，也是工程师避免数据误读的实用指南。
这篇博文通过清晰的可视化对比，有力地揭示了仅依赖平均值或单一百分位数做技术决策的陷阱，并提供了可直接复现的分析方法。其核心方法（尤其是 CDF 对比和位移函数）可迁移到任何涉及分布变化分析的场景，如性能优化、A/B 测试或系统监控。适合所有需要从数据中提取可靠结论的后端工程师、SRE 和数据分析师，是一份长期值得参考的实践指南。
技术文章 Fzakaria Blog 2026/07/27
文章深入分析 x86-64 大代码模型（-mcmodel=large）在处理线程局部存储（TLS）时的根本性缺陷。作者通过构造超过 2 GiB 的 .bss 和 .text 示例，对比普通数据访问与 TLS 访问的编译器重定位类型，指出尽管大代码模型为普通数据生成了 64 位重定位，但 TLS 访问序列仍使用 32 位立即数（如 R_X86_64_TPOFF32），导致二进制文件超出 2 GiB 时链接失败。进一步剖析 GCC 与 LLVM 生成的指令序列，揭示问题并非编译器实现缺陷，而是 x86-64 psABI 从未定义大代码模型下的 TLS 访问模式，使得 64 位 TLS 偏移无法编码到指令中。文章提供了可复用的 Python 脚本用于生成巨型目标文件，验证了现象的通用性，并指出该限制对有大量线程局部变量的静态链接可执行文件尤为严重。
本文并非泛泛而谈，而是通过可复现的构造实验和汇编级分析，定位到 x86-64 ABI 规范的一项具体缺失，揭示了大型二进制工程中的一个隐蔽陷阱。其直接证据清晰、方法可迁移，适合从事工具链、系统软件或性能敏感大型应用开发的读者参考。文章还提供了生成测试用例的脚本，有助于读者在自己的环境中验证和延伸研究，具备长期的参考价值。
技术文章 Fzakaria Blog 2026/07/21
本文介绍了作者通过向 Linux 内核提交补丁，使内核支持在 PT_INTERP 和 shebang 中使用 $ORIGIN 的过程。最初提议在 VFS 层直接添加支持，经 VFS 维护者 Christian Brauner 建议，最终采用 eBPF 和 binfmt_misc 实现可编程解释器选择。文章展示了具体的 eBPF 程序示例，并讨论了新的 loader substitution 模式（L 标志），该模式允许原生执行二进制文件并透明替换解释器，解决了传统 binfmt_misc 中进程标识和 /proc/self/exe 指向解释器的问题。作者计划在相关补丁进入内核主线后，为 NixOS 开发一个可选模块，通过引入新的程序段（如 PT_INTERP_NIX）来保持向后兼容性。该方法不仅支持 $ORIGIN，还可用于动态选择 QEMU 等解释器，边界在于需要内核版本支持且依赖 binfmt_misc 和 eBPF 基础设施。
本文记录了真实的内核开发协作过程，从动机、技术方案迭代到最终实现，展示了如何利用 eBPF 和 binfmt_misc 解决可重定位二进制文件的痛点。对 Linux 内核开发、Nix/Bazel 等构建系统使用者以及关注动态链接器机制的技术人员有直接参考价值，其可编程解释器选择的思路可迁移至其他需要动态加载或仿真环境的场景。
工程实践 Fzakaria Blog 2026/07/21
文章记录了作者为支持 Nix 的 relocatable binaries 而向 Linux 内核提交补丁的完整过程。最初尝试在 VFS 层直接支持 $ORIGIN 失败后，在 VFS 维护者 Christian Brauner 的建议下，转而利用 eBPF 和 binfmt_misc 实现可编程解释器选择。最终方案通过 eBPF 程序在运行时根据 ELF 文件路径动态确定解释器，无需修改内核主体，并衍生出新的分发模式（如 loader substitution 'L'）以解决传统 binfmt_misc 导致的进程身份透明性问题。文章还讨论了该机制在 QEMU、shebang 等场景的扩展潜力，并保留了向后兼容性设计——通过新增 PT_INTERP_NIX 段来控制触发。作者展望了在 NixOS 中的集成计划，同时坦诚说明了内核参与门槛、eBPF 所需的配置依赖等边界。
该文以一线开发者的视角完整呈现了一项内核特性的工程实现路径，从问题定义、社区协作、技术方案演化到最终合入主线的全过程，具有很高的可迁移价值。对从事包管理、容器化或需要定制可执行文件加载流程的工程师而言，它不仅展示了 eBPF 在系统软件中的创新用法，还深入分析了 binfmt_misc 的传统缺陷与改进思路，是理解现代 Linux 可执行文件加载机制和内核贡献方法论的良好参考。
技术文章 Fzakaria Blog 2026/07/09
文章介绍了一款名为 anubis-fetch 的工具，用于绕过 Anubis 防火墙的工作量证明（PoW）挑战。作者首先描述了为 Linux 内核 BPF binfmt_misc 开发补丁时，遇到 AI 工具无法直接抓取 lore.kernel.org 的问题，继而开发了该工具。工具通过原生实现 PoW 求解、可选的 Chromium 回退，以及对 Chrome TLS/JA3 指纹的模拟，成功绕过了 Anubis 及 Cloudflare 的被动封锁。文章进而批判了 Anubis 的无效性：攻击者可以轻易摊销一次性成本，而人类用户每次访问都要付出等待时间和设备能耗，尤其对移动端、屏幕阅读器等用户形成排斥。作者通过粗略计算，估算了全球范围因 Anubis 挑战消耗的人数和能源，指出这种措施更像是一种累退税，未能阻止真正的 AI 爬虫，反而损害了开放 Web。全文兼具工具实现细节与社会影响分析，边界清晰，不涉及复杂系统设计，但提供了可复现的方法和对反爬技术局限的反思。
推荐收录，因为它不仅是一个工具介绍，更包含了对反爬技术的深度批判和实证分析。文中直接展示了绕过 Anubis 的具体代码思路与效果，并通过估算了这种防御措施对人类用户造成的隐性代价，证据充分。这篇文章适合安全工程师、Web 开发者以及关注互联网开放性的读者，其可迁移价值在于提醒设计反爬系统时需权衡防御真实威胁与用户体验的平衡，避免累退性设计。
个人心得 Fzakaria Blog 2026/06/29
文章回顾了作者在墨西哥 La Saladita 组织的 TacoSprint 2026，这是一场面向 Nix 社区的首次北美 sprint。作者从选址、搭网站、拉赞助到招募参与者，详细记录了新活动在报名不足、旅行安全顾虑和航班紧张上的现实阻力。活动期间，冲浪与编码交替的日程让团队保持了稳定节奏，并在一周内推进了动态链接、可重定位二进制、远程构建、模块系统、OCaml 运行时裁剪和跨发行版打包等工作。文中还提到 LLM agents 的交流，以及一篇仿学术风格的 trip report，整体更偏社区组织与生产力经验，而非单点技术教程。
可收录，因为它直接呈现了首个北美 Nix sprint 的组织过程、现实阻力和可持续协作节奏，适合开源社区组织者、Nix 贡献者和想提升团队产出的读者。需要注意的是，文章主要是 retrospective，技术细节分散，不适合作为某一技术方案的深入参考。
技术文章 Fzakaria Blog 2026/06/23
这篇文章深入讲解了 wrap-buddy 如何通过篡改 ELF 入口点、动态段和辅助向量，绕过 NixOS 上预编译二进制因动态链接器路径不兼容而无法运行的问题。作者先用一个最小 C 程序演示 patchelf/autoPatchelf 在特殊 ELF 布局下的失败场景，再逐步拆解 wrap-buddy 的做法：保存原始入口指令、清空 PT_INTERP、注入自定义 RUNPATH，并在内存中恢复原样后把控制权交给 NixOS 的动态加载器。文章的核心结论是：这种方案并不是通用替代品，而是面向“常规修补失效”的病理场景，为旧二进制兼容性提供了一条极低层但有效的路径。
推荐收录，因为它不是简单介绍 Nix 工具链，而是把 ELF 启动、动态链接与启动劫持的机制讲得非常透彻，适合长期作为系统底层兼容性问题的参考。读者可以迁移的不只是某个工具的用法，更是“当静态修补失败时，如何从进程启动链路下手”的分析方法。