Why Work in the Frequency Domain In the previous post we built the image degradation model: the observed image $g(x,y)$ is the original image $f(x,y)$ convolved with a degradation function $h(x,y)$ and corrupted by additive noise $n(x,y)$: $$g(x,y) = h(x,y) * f(x,y) + n(x,y)$$Restoration means: given $g$ and $h$, recover $f$ as closely as possible. In the spatial domain, this requires solving a deconvolution problem. Deconvolution is a massive linear system. For a $512 \times 512$ image, you face 260,000 unknowns. Direct solving is practically impossible.

The first two articles covered eBPF fundamentals and OOM Killer event tracing. This article goes deeper: container-level OOM pinpointing, real-time memory allocation rate tracking, and implementing the same functionality with the Rust Aya framework. Container-Level OOM Pinpointing In Kubernetes, “a Pod OOM’d” is actually a vague statement. A Pod consists of multiple containers, each belonging to different cgroups. eBPF can drill through this layer and precisely identify which container and which process caused the OOM.

bpftrace is great for quick probing and ad-hoc debugging. For production-grade monitoring tools, you need full eBPF programs. The architecture splits into two layers: Kernel side: eBPF program written in C, attached to hook points, collecting event data User side: loader written in Go (or Rust / libbpf C), loading the eBPF program and reading events Architecture mermaid flowchart TD classDef kern fill:#bbdefb,stroke:#2196F3,color:#1B5E20 classDef user fill:#fff3e0,stroke:#FF9800,color:#BF360C classDef data fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20 hook@{ shape: rounded, label: "oom_kill_process (kprobe)" } ebpf@{ shape: proc, label: "eBPF Program\nEvent Collection" } ring@{ shape: cyl, label: "Ring Buffer" } loader@{ shape: notch-rect, label: "bpf2go Loader" } reader@{ shape: proc, label: "RingBuf Reader\nEvent Parsing" } hook --> ebpf --> ring ring --> reader loader -.-> ebpf class hook,ebpf kern class ring data class loader,reader user eBPF Kernel Program (C) Name the C file oom_kprobe.bpf.c — the bpf suffix is a cilium/ebpf convention for bpf2go code generation:

eBPF (Extended Berkeley Packet Filter) started as a network packet filtering tool, but over nearly a decade it has evolved into a mainstream observability framework in the Linux kernel. It allows you to safely inject and execute custom programs without modifying kernel source code or loading kernel modules. This article kicks off the series, using OOM (Out-of-Memory) monitoring as a concrete entry point to learn the core eBPF concepts and toolchain.

What Is Loop Engineering? Definition (Addy Osmani, June 2026): Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. The loop is a recursive goal where you define a purpose and the AI iterates until complete. Simply put: Loop Engineering = letting the system start its own workflows. Example: Traditional way: You discover bug → You say “fix this bug” → AI fixes it Loop Engineering: System automatically discovers bug → System says “fix this bug” → AI fixes it Origins The evolution of this concept:

Why Interpolation Matters Imagine you have a low-resolution photo and want to print it larger. Between every two pixels in the original image is now a “blank space” — where do the new pixels come from? Interpolation is the solution: using known pixel values to estimate values at unknown positions. Image upscaling is essentially an interpolation problem. $$ \text{Upscaled Image} = \text{Interpolation Algorithm}(\text{Original Pixels}) $$The quality of interpolation directly affects the upscaled image. Too simple methods produce mosaic artifacts, while too complex methods may introduce ringing artifacts. Let’s progress step by step, from the simplest nearest neighbor interpolation to the most commonly used bicubic interpolation.

Why Do Photos Get Blurry? Scrolling through your phone gallery, you will always encounter such regrets: at the moment you pressed the shutter, you captured a beautiful moment, but the photo turned out blurry — maybe due to shaky hands, insufficient light, or the subject moving too fast. Old photos are even worse — the passage of time makes memories from back then become fuzzy. Blur is not accidental. In the world of digital imaging, every photo undergoes a complex transformation process from the real scene to digital signals. Light passes through the lens, falls on the sensor, gets recorded by electronic systems — every link may introduce “degradation.” Understanding how these degradations occur is the first step to studying image restoration from a mathematical perspective.

The concurrently released MiBeeNvr v0.6.0 brought major features like timelapse, video transcoding, and ONVIF enhancements. Unit tests alone are far from enough — the full workflow must be tested against real camera hardware. To provide reliable test machines for this release, three camera projects were updated on the same day, June 5th — both to supply testing environments for the NVR and to solve some typical embedded development engineering problems along the way.

After running continuous recording for a few weeks, storage became the first bottleneck. A single 1080p camera writes tens of GB per day — with a 30-day retention policy, a 1TB drive is mostly consumed. Many community members reported the same issue, and during discussions, the ideas of timelapse and transcoding storage gained the most traction: most of the time the scene is static, and compressing it with timelapse requires only 5% of the space for the same duration.

After the journey of the first four articles—ownership and borrowing, type system, error handling, and pattern matching—we have now reached the Rust chapter finale, time to tie the scattered knowledge together. This article focuses on Rust’s standard library concurrency tools and the async/await ecosystem. These are the most interesting comparative points between Rust and Go in the concurrency domain: Go makes concurrency look simple through goroutines and channels, while Rust makes concurrency safe and reliable through strict type systems and ownership constraints.