v0.6.0 把延时摄影管道搭起来之后，社区反馈很快就指出了几个硬伤：JPEG 序列要吃掉太多存储、H.265 摄像头生成的延时片段播放不了、双摄小米设备只能抓到主镜头、偶尔还会出现 H.265 HLS 直接 panic 的崩溃。这些都不是边缘场景——双摄 CW500 和室外摄像头 4 在国内出货量很大，H.265 已经是中高端摄像头的事实标准。v0.7.0 的主线就是围绕这些反馈展开的。

Zhi 主题 发布了 v0.2.0——这是从 4 月份 初次发布 后最重要的功能更新。这次发布的三个重头功能——多语言切换、文章系列（Series）分类法、Mermaid v11+ 升级——都是在自己使用过程中逐步积累的需求。

前几篇文章展示了如何使用 eBPF 追踪 OOM 事件。但这还不够——我们只是在"看"，不能"管"。内核的 OOM Killer 选谁杀谁，由 oom_badness() 算法决定，用户无法干预。

前两篇文章覆盖了 eBPF 基础概念和 OOM Killer 事件追踪。这篇文章进入更深的层次：容器级别的 OOM 定位、内存分配速率的实时追踪，以及用 Rust Aya 框架来实现同样的功能。 容器级 OOM 定位 在 Kubernetes 环境中，“某个 Pod OOM 了"实际上是一个模糊的描述。Pod 由多个容器组成，容器可能属于不同的 cgroup。eBPF 可以穿透这一层，精确地定位到"是哪个容器里的哪个进程"导致了 OOM。

bpftrace 适合快速探查和临时调试，但如果要构建持续运行的生产级监控工具，就需要完整的 eBPF 程序了。典型的架构分两层： 内核态：用 C 编写 eBPF 程序，挂载到 hook 点，采集事件数据 用户态：用 Go（或 Rust / libbpf C）编写 loader，加载 eBPF 程序并读取事件 这个模式在行业里已经非常成熟——Pixie、Parca、Cilium 等开源项目都遵循这个架构。

eBPF（Extended Berkeley Packet Filter）最初是网络包过滤工具，经过近十年发展，已经成为 Linux 内核最强大的可观测性框架。它允许你在不修改内核源码、不加载内核模块的前提下，安全地注入并执行自定义程序。

MiBeeNvr 连续跑了几周录像后，存储最先告急。单路 1080p 摄像头每天要写几十 GB，30 天留存一件 1TB 硬盘就没了大半。社区里不少朋友反馈了同样的问题，讨论中延时摄影和转码保存的方案呼声最高——画面大部分时间静止，用 timelapse 压缩后同样时长只需要 5% 的空间。

同期发布的 MiBeeNvr v0.6.0 带来了延时摄影、视频转码、ONVIF 增强等大功能，光靠单元测试远远不够，必须在真实摄像头环境下跑完整流程。为了给这个版本提供靠谱的测试机器，6 月 5 日同一天更新了三个摄像头项目——既是给 NVR 提供测试环境，也顺手解决了一些嵌入式开发中比较典型的工程问题。

v0.4.0 发布不到一周，又肝了 31 个提交。v0.5.0 是一个功能密度很高的版本：ONVIF 全协议支持（Device/Media/PTZ/Imaging/Event 五大服务全覆盖）、硬件转码（H.265 → H.264）、录制器重连优化。127 个文件变更，+24,509 / -730 行。完整更新列表见 GitHub Release Notes。

第 9 章：Rust 使用 YOLO 完整教程 Rust 凭借内存安全、零成本抽象、极致性能三大特性，成为 YOLO 生产级部署的终极选择。在边缘计算、高并发场景下，Rust 的性能优势尤为显著。