技术文章 Null Program 2026/11/05
文章讨论终端程序的行缓冲输出为何会成为非交互场景的性能瓶颈，并以 unzip 逐文件打印为例说明其开销。作者先剖析 glibc 和 CPython 在换行时刷新的不同实现，再给出带 BUF_LINE 标志和批量 append 的缓冲区结构。核心方案借鉴 Nagle 算法，用单调时钟设置约 100ms 的 deadline，在工作间隙检查并刷新，而不是每遇到换行就写一次。这样既保证终端及时看到输出，又能合并多次小写提升吞吐，且无需额外线程。其适用边界是调用方需主动在短任务间调用 deadline_flush，并调整缓冲区接口；对延迟极敏感或无法插入检查点的场景仍需另行权衡。
推荐收录。文章从可复现的 strace 现象出发，比较 glibc/CPython 行缓冲行为，给出可运行的 C 缓冲区实现和 deadline_flush 设计，并明确说明需调用方在工作间隙刷新这一工程约束。对编写 CLI、终端工具或系统 I/O 代码的读者，这种以合并小写替代逐行 flush 的思路可直接迁移，也能帮助判断何时不应依赖 stdio 默认缓冲。
工程实践 Null Program 2026/10/31
作者介绍自研的本地 LLM 编码代理工具 Prospero：用 C++/Dear ImGui 做桌面界面，不内置模型供应商，需自行接入 llama.cpp 或 OpenAI 兼容端点，并支持子代理、无头远程部署、桌面控制和 MCP。文章把编码 harness 视为模型循环调用 shell 与文件工具的薄层，提出“永不无限等待”和“进程树同生共死”原则：所有操作设超时，同步超时可转后台任务，命令终止时清理整个进程树。为降低资源占用，界面采用被动渲染，配置用可 include 的 INI；作者还指出权限系统只能减少误操作，不能阻止恶意代理。文章偏产品发布与设计原则概览，缺少实现细节、基准数据和独立验证，商业分层需读者自行评估。
推荐收录为工程案例。文章没有停留在功能清单，而是围绕编码代理的资源占用、超时控制、进程清理和远程部署给出可迁移的设计约束，“永不无限等待”和“进程树同生共死”对构建可靠的 agent harness 有直接参考价值。读者应把它当作设计原则概览而非可复现评测，商业分层和缺少量化基准是主要限制。
工程实践 Null Program 2026/10/04
作者回顾自己博客从 Perl blosxom、Jekyll（Ruby/GitHub Pages）迁移到自研静态站点生成器 ssg 的过程。ssg 以 C++20 的“C with templates”风格编写，约 8KLoC、零依赖、核心不依赖 libc，采用 unity build，冷启动全站生成约 150ms，而原 Jekyll 方案约 2 秒；作者指出真正痛点其实是 Ruby 在 macOS 上的部署体验，而非渲染性能。迁移分三步：先修掉多年累积的站点 bug，再让两套生成器并行输出做对比，最后删除 Liquid 模板并改为动态生成标签页，同时保留原有 feed UUID。文中还披露 ssg 主要由 AI 模型在约两小时、约二十分钟提示词下生成，风格与其本人高度一致，与其两年前“AI 代码不实用”的判断形成反转。边界在于 ssg 只服务单一站点、并非通用生成器，AI 效果也属单例经验。
推荐收录：文章给出可验证的工程证据，包括 8KLoC 单文件、零依赖、unity build、150ms 冷生成、Windows XP 可构建，以及对 Jekyll 部署痛点的具体取舍，属于真实且可迁移的构建与工具链经验。更有价值的是它记录了一个 AI 按个人编码哲学生成可用 C++ 程序的完整案例，对关注 AI 辅助编程、开发者工具与个人基础设施的读者都有参考意义；局限是单一站点与单次 AI 实验，通用性需谨慎看待。
工程实践 Null Program 2026/09/20
本文盘点 w64devkit 过去一年的演进，覆盖发布安全、工具链、新工具与运行时。发布侧引入代码签名、GitHub Actions 自动构建和不可篡改发布，签名工具 aas-sign 被 MSYS2 采用；x64 版本改为 multilib，可用 -m32 或 i686-w64-mingw32 前缀工具编译 32 位程序。工具链侧，Binutils 现在按需自动升级到 bigobj COFF，缓解 C++ 大工程链接失败并恢复 cgo，静态运行时从 -Os 改为 -O2。新增 CMake/Ninja、Ccache、quilt、NSIS、zstd、widl 等工具，并重写 C11 threads 实现（基于 SRW 锁，需 Windows 7+，不含递归锁）。未来计划分发 FatLTO 运行时并重新启用 LTO，但作者对 Fortran 运行时错误仍缺乏信心，上游拒收相关补丁。
推荐收录：文章不是简单的新版本通告，而是给出了发布签名与不可篡改发布的具体做法、Binutils bigobj 自动升级的原因与取舍、从 -Os 转向 -O2 的依据，以及 C11 threads 实现中对标准缺陷的批评。对维护 Windows 交叉工具链、构建分发或发布安全的开发者有直接参考价值，其中 LTO 缺陷修复与 FatLTO 设想也可迁移到其他编译器分发场景。
工程实践 Null Program 2026/09/17
文章介绍作者为 1995 年的 16 位 Windows 4X 游戏 Stars! 构建 Stars!VM：它内嵌 80286 模拟器和 Win16 到 Win32 桥，使老游戏以原生 Win32 程序运行，并保留现代文件选择器与 4K 缩放。模拟器直接调用宿主 x87 硬件处理 80 位浮点，并用差分模糊测试随机指令与 JIT 结果对比来验证正确性；桥接层负责映射句柄、转换结构布局和处理 DOS 中断。作者还通过 MCP 暴露 UI DOM 与客户机内存，让 AI 代理注入事件甚至完整试玩一局。性能上，基于指令 trace 反向工程热点例程并改写为新 80286 指令，使回合生成约提速 2 倍，同时缓冲 I/O、原生实现 WaveMix.dll、压缩资源，并注入序列号和固定硬件签名绕过拷贝保护。方案依赖 x86/x86-64 与 SSE2，且不实现软件 x87，适用边界较明确。
推荐收录。文章给出一个真实且完整的遗留系统复活案例：从 80286 仿真、Win16/Win32 桥接、差分模糊验证，到 trace 驱动热点优化和 MCP 代理接口，都有具体约束、取舍与验证证据。适合对模拟器、系统编程、逆向工程和遗留软件迁移感兴趣的读者，其中的差分测试、指令级补丁和 I/O 缓冲思路可迁移到其他兼容层或运行时项目。