I’ve been blogging for over a year now, and I’ve drawn dozens of diagrams. Architecture diagrams, sequence diagrams, data comparison bar charts, TCP congestion window evolution curves.
Then one day on my commute home, it hit me: I’ve been using Mermaid almost daily, but I have no idea what technology powers it.
You write a ```mermaid code block, save the file, and there it is—a fully rendered diagram. But how does text become SVG? What even is SVG? Why do I use Chart.js for bar charts and ECharts for stacked line charts? What if I need a real-time dashboard, not just a static diagram?
As a studio operator, the biggest pain point is never a specific problem — it’s the “not knowing” when devices multiply.
Not knowing which devices are alive, what services are running on them, whether a new machine has appeared on the network, whether a certain port is still open. This accumulated “not knowing” eventually becomes an outage.
My previous approach was a patchwork: Zabbix for monitoring, Nmap for scanning, Excel for asset tracking, Prometheus for metrics. Each tool is fine on its own, but together they’re a disaster — data silos, duplicate configuration, version drift, complex deployment.
It doesn’t matter how good your content is — if search engines can’t crawl it and users can’t find it, it might as well not exist. That sounds harsh, but for the vast majority of independent blogs it’s simply the truth. Your server sits on some VPS, your domain has little authority, backlinks are scarce, and Googlebot might swing by only once a month — and every time it does, it sees the same content from weeks ago. The keywords readers type into the search box will never point to your pages. A painstakingly polished technical article ends up gathering dust in your own archive page.
How do NVR (Network Video Recorder) systems let mobile apps view surveillance feeds from any network? This is a core requirement for the security industry and smart home ecosystems. This article systematically surveys three dimensions: open-source NVR projects (Frigate, go2rtc, Kerberos.io, Agent DVR, etc.), commercial surveillance vendors (Hikvision, Dahua, EZVIZ, Ubiquiti, Synology, Reolink, etc.), and third-party P2P platforms and security research (TUTK Kalay, iLnkP2P/PPPP, GB/T 28181, key CVEs).
All technical descriptions are verified against primary sources—official documentation, security advisories, and academic papers. Key statistics include citations.
Building a self-hosted P2P signaling and relay server is the core infrastructure for cross-network connectivity, remote access, and mesh VPN scenarios. This article systematically surveys the complete technology landscape across three dimensions: protocol standards (STUN/TURN/ICE/BEHAVE), mainstream products (Tailscale, Nebula, NetBird, ZeroTier, Headscale, OpenZiti, etc.), and frameworks & algorithms (libp2p, WebRTC, Kademlia DHT).
All technical descriptions are verified against primary sources—RFC originals, academic papers, and official documentation. Key statistics include citations.
To push camera feeds from the MiBee NVR project to a domestic live-streaming platform, there are three candidates: call FFmpeg directly, use the pure-Go gortmplib, or use go2rtc. All three “do RTMP”, but their behaviour against Chinese live-streaming platforms differs wildly — some disconnect instantly, some after a few seconds, some are rock solid. This post tears all three apart at the source level, and walks through the pitfalls and fixes for integrating with FMS-compatible domestic platforms.
The previous 7 articles broke down the storage architectures of each observability domain—TSDB, logging, tracing, RUM, profiling, and eBPF. This one pulls them together: how to pick storage for your scenario. Teams differ in scale, tech stack, budget, and requirements—there is no “best” storage, only the one that fits you.
Picking storage is a bit like picking a car—a startup needs a cost-efficient compact (Loki + VictoriaMetrics), an enterprise with compliance needs wants a heavy-duty truck (Elasticsearch), and a platform team wants a versatile van (ClickHouse unified). It comes down to four dimensions: data volume, query patterns, budget, and team size. The animation below walks three typical scenarios through the decision matrix:
About This Handbook This handbook covers 20 mainstream embedded camera modules — 8 OV/GC series (OV2640, OV5640, OV7725, GC0309, OV7670, OV3660, GC2053, GC4653) and 12 Sony IMX/OV MIPI series (IMX219, IMX273, IMX296, IMX307, IMX335, IMX415, IMX477, IMX678, IMX708, IMX766, plus OV9281 and OV5647). All parameters are sourced from official datasheets, with sources noted at the end of each section.
Quick Selection Guide Start with this table to find your use case, then read the details below.
This post implements core image restoration algorithms in Go and Rust, comparing the two languages’ approaches to image processing through practical code.
原始图像 退化图像 — — Go Implementation Go’s standard image library provides image encoding/decoding and pixel access. The following implementation demonstrates how to implement bicubic interpolation, Gaussian blur, and Laplacian sharpening in Go.
Observability architecture has shifted from “fragmented” to “unified” over the past five years. Signals (metrics, logs, traces, profiling) have moved from independent specialized backends toward shared storage and a unified data model, while eBPF, as a next-generation collection mechanism, provides finer data granularity and broader coverage for this transformation. This article focuses on four dimensions: eBPF collection storage design, unified storage architecture (LGTM fragmented vs ClickHouse unified), the OpenTelemetry unified data model, and the evolution of object storage with compute-storage separation.