From Mathematical Models to Data-Driven Learning In super-resolution tasks, traditional methods rely on carefully designed mathematical models—interpolation algorithms, sparse representation, prior constraints, and so on. But deep learning brought a paradigm shift: directly learning the mapping from degraded space to clear space from massive paired low-resolution (LR) and high-resolution (HR) image data. The core idea is simple: train a neural network $F_{\theta}$ that can map low-resolution images to high-resolution images:

Distributed tracing storage is one of the most technically divergent areas in the observability landscape. Unlike metrics and logging, which have relatively converged storage patterns (TSDB and ClickHouse-like systems), tracing storage has split into three distinct paths due to fundamental disagreements over indexing strategy. This chapter analyzes the storage architectures of Jaeger, Grafana Tempo, Apache SkyWalking, Zipkin, and the commercial solutions from Datadog and Splunk, concluding with a horizontal comparison.

Introduction Logs generate the largest data volume and highest storage cost among the three pillars of observability. Unlike metrics with their fixed numeric structure, logs are variable-length text with semi-structured characteristics, posing unique storage design challenges: supporting full-text search while controlling storage costs. The core design dimension of log storage systems is indexing strategy — deeper indexing means faster search, but also higher storage costs. From Elasticsearch’s full inverted index to Loki’s label-only indexing, each system makes different technical choices along this spectrum.

The previous post introduced frequency domain image processing methods — transforming images to the frequency domain via Fourier transform, then performing filtering, restoration, and other operations. However, frequency domain methods are sometimes less intuitive, especially when we’re more accustomed to directly manipulating pixels. Spatial domain methods process images directly in pixel space, without requiring transformations. This chapter introduces spatial domain image restoration, edge-preserving filtering, and sharpening techniques. Lucy-Richardson Iterative Deconvolution The goal of deconvolution is to recover the original image from a degraded image. The degradation process is typically modeled as convolution: degraded image = original image convolved with blur kernel + noise.

Introduction Time-Series Databases (TSDB) are the foundation of observability storage. The previous post outlined the main threads of storage evolution; this post focuses on the TSDB category—comparing the storage engines of four mainstream TSDBs: InfluxDB, Prometheus, VictoriaMetrics, and TimescaleDB. Whether you use Prometheus or are evaluating VictoriaMetrics, understanding the design tradeoffs of the underlying storage engines helps with more effective selection and usage.

Why Understanding These Four Stages Matters AI engineering has gone through four paradigm shifts between 2022 and 2026. If you only master Prompt Engineering, you’ve covered just one of these stages. Learning to program with only print statements—without functions, classes, or frameworks—won’t let you write real programs; the same holds for AI engineering. These four stages form a complete capability ladder, and skipping any step will limit you in practice.

Zhi theme v0.2.0 is out — the most significant feature update since the initial release back in April. This release addresses real needs accumulated from personal usage and iterative development. In a nutshell: Language switcher: Globe icon button with CSS dropdown, auto-linking translated pages Post Series: Series overview page (card layout) + detail page (stepper/timeline layout) with sort toggle Mermaid v11+: Async render API with reliable dark mode adaptation Plus a slew of bug fixes and comprehensive documentation updates Let’s walk through each feature.

Introduction Observability is a core component of cloud-native infrastructure. The five signals—Metrics, Logs, Traces, RUM, and Profiling—each generate massive volumes of data, and their storage efficiency directly determines platform cost boundaries and query performance. On the collection side, eBPF is reshaping how data is acquired; on the storage side, storage architecture evolution is the underlying foundation that enables observability to scale in production. mermaid flowchart TD A[Five Signals of<br/>Observability] --> B[Metrics] A --> C[Logs] A --> D[Traces] A --> E[RUM + Profiling] style A fill:#9C27B0,color:#fff style B fill:#2196F3,color:#fff style C fill:#2196F3,color:#fff style D fill:#2196F3,color:#fff style E fill:#2196F3,color:#fff mermaid flowchart TD G[Storage Evolution<br/>Convergent Paths] --> H[Proprietary Format<br/>→ Columnar Standard] G --> I[Index Bloat<br/>→ Weak Index + Object Store] style G fill:#FF9800,color:#fff style H fill:#4CAF50,color:#fff style I fill:#4CAF50,color:#fff Figure: The five observability signals each produce data with different characteristics, yet their storage evolution converges on two core themes across all signals: the shift from proprietary storage formats to Parquet/Arrow columnar standards, and the move from full-field inverted indexes to weak-index strategies with object storage.

After v0.6.0 put the timelapse pipeline in place, community feedback quickly pointed out several hard problems: the JPEG sequence consumed too much storage, H.265 cameras couldn’t generate playable timelapse segments, dual-lens Xiaomi devices could only capture the main lens, and H.265 HLS would occasionally panic outright. None of these are edge cases — the dual-lens CW500 and Outdoor Cam 4 ship in large volumes in China, and H.265 is the de facto standard for mid-to-high-end cameras. The v0.7.0 mainline was built around exactly this feedback.

The previous articles showed how to use eBPF to observe OOM events. But we could only watch, not intervene. The kernel’s OOM Killer decides who lives and dies based on the oom_badness() algorithm, with no user control. In 2025, Google engineer Roman Gushchin proposed the BPF OOM kernel patch series, aiming to let eBPF programs fully take over OOM handling policy. This is the biggest change to Linux memory management’s OOM subsystem in nearly two decades.