From 74b551464c6daf87617fea550d2592e7c2e20be0 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sun, 10 May 2026 22:43:47 +0300 Subject: Update content for gemtext --- gemfeed/2026-05-11-unveiling-ior-ng-part-2.gmi | 20 +++++++++++++++----- gemfeed/2026-05-11-unveiling-ior-ng-part-2.gmi.tpl | 11 ++++++++++- gemfeed/atom.xml | 20 ++++++++++++++++---- gemfeed/index.gmi | 2 +- index.gmi | 4 ++-- uptime-stats.gmi | 16 ++++++++-------- 6 files changed, 52 insertions(+), 21 deletions(-) diff --git a/gemfeed/2026-05-11-unveiling-ior-ng-part-2.gmi b/gemfeed/2026-05-11-unveiling-ior-ng-part-2.gmi index d41084df..c0cbb147 100644 --- a/gemfeed/2026-05-11-unveiling-ior-ng-part-2.gmi +++ b/gemfeed/2026-05-11-unveiling-ior-ng-part-2.gmi @@ -1,4 +1,6 @@ - (or Podman)# Unveiling I/O Riot NG — Part 2: install and compile once, run everywhere +# Unveiling I/O Riot NG — Part 2: install and compile once, run everywhere + +> Published at 2026-05-10T22:43:39+03:00 This is Part 2 of three. Part 1 is the demo-driven tour: what ior looks like, how the dashboard tabs work, how filtering and recording behave. This part is about the installation for Rocky Linux 8 and 9 and, more interestingly, why you only have to do that dance on a single machine: the resulting binary is portable to every other Linux box thanks to CO-RE (Compile Once, Run Everywhere) plus full static linking. Part 3 is the under-the-hood companion (per-event schema, async-syscall caveats, the syscall-coverage probe generator, and post-mortem SQL on the parquet output). @@ -9,10 +11,7 @@ This is Part 2 of three. Part 1 is the demo-driven tour: what ior looks like, ho ## Table of Contents -> Published at 2026-05-10T22:41:23+03:00 - -> Published at 2026-05-10T22:39:24+03:00 - +* ⇢ Unveiling I/O Riot NG — Part 2: install and compile once, run everywhere * ⇢ ⇢ Installing ior * ⇢ ⇢ ⇢ Why native installation is a mess * ⇢ ⇢ ⇢ What the Docker build is actually doing @@ -27,6 +26,10 @@ This is Part 2 of three. Part 1 is the demo-driven tour: what ior looks like, ho ## Installing ior +> Published at 2026-05-10T22:41:23+03:00 + +> Published at 2026-05-10T22:39:24+03:00 + The short answer: Use Docker (or Podman). One command, no toolchain setup, works from any Docker-capable Linux host with BTF available: ```sh @@ -112,6 +115,8 @@ If you see `Probing for 5s` followed by CSV rows, the build is good. `mage build If you haven't touched eBPF before: it's a small in-kernel bytecode VM. You compile a tiny C program, the kernel verifies it can't crash or loop forever, and then it runs every time some hook fires — a syscall enter/exit, a kprobe, a tracepoint, a network packet. The program writes events into a ring buffer that userspace mmaps and drains. No kernel module, no patched kernel, no debug symbols required. +=> https://ebpf.io eBPF — the project's umbrella site (docs, talks, ecosystem) + `ior` plugs into the syscall tracepoints (`sys_enter_openat`, `sys_exit_read`, etc.) and the BPF side does the bare minimum: timestamp the event, copy a few fields, push to a perf ring buffer. All the heavy lifting (string interning, latency math, aggregation, the dashboard) is in Go on the userspace side. The shape of the data flow: @@ -139,9 +144,14 @@ The shape of the data flow: The kernel ships a C library called libbpf that handles loading the program, attaching it to hooks, managing maps, and reading the ring buffer. There are two well-known ways to drive that from Go: +=> https://github.com/libbpf/libbpf libbpf — the upstream C library + * libbpfgo (Aqua Security): a thin cgo wrapper around libbpf. You ship libbpf along with your binary and call into the same C API that `bpftool` and `perf` use. * cilium/ebpf: a from-scratch pure-Go reimplementation of everything libbpf does (ELF parser, BTF resolver, syscall layer, the lot). +=> https://github.com/aquasecurity/libbpfgo libbpfgo — Aqua Security's cgo wrapper around libbpf +=> https://github.com/cilium/ebpf cilium/ebpf — pure-Go reimplementation + I went with libbpfgo specifically because it's a wrapper, not a reimplementation. ## CO-RE — the part that makes the binary actually portable diff --git a/gemfeed/2026-05-11-unveiling-ior-ng-part-2.gmi.tpl b/gemfeed/2026-05-11-unveiling-ior-ng-part-2.gmi.tpl index 7539c969..b207fe39 100644 --- a/gemfeed/2026-05-11-unveiling-ior-ng-part-2.gmi.tpl +++ b/gemfeed/2026-05-11-unveiling-ior-ng-part-2.gmi.tpl @@ -1,4 +1,6 @@ - (or Podman)# Unveiling I/O Riot NG — Part 2: install and compile once, run everywhere +# Unveiling I/O Riot NG — Part 2: install and compile once, run everywhere + +> Published at 2026-05-10T22:43:39+03:00 This is Part 2 of three. Part 1 is the demo-driven tour: what ior looks like, how the dashboard tabs work, how filtering and recording behave. This part is about the installation for Rocky Linux 8 and 9 and, more interestingly, why you only have to do that dance on a single machine: the resulting binary is portable to every other Linux box thanks to CO-RE (Compile Once, Run Everywhere) plus full static linking. Part 3 is the under-the-hood companion (per-event schema, async-syscall caveats, the syscall-coverage probe generator, and post-mortem SQL on the parquet output). @@ -99,6 +101,8 @@ If you see `Probing for 5s` followed by CSV rows, the build is good. `mage build If you haven't touched eBPF before: it's a small in-kernel bytecode VM. You compile a tiny C program, the kernel verifies it can't crash or loop forever, and then it runs every time some hook fires — a syscall enter/exit, a kprobe, a tracepoint, a network packet. The program writes events into a ring buffer that userspace mmaps and drains. No kernel module, no patched kernel, no debug symbols required. +=> https://ebpf.io eBPF — the project's umbrella site (docs, talks, ecosystem) + `ior` plugs into the syscall tracepoints (`sys_enter_openat`, `sys_exit_read`, etc.) and the BPF side does the bare minimum: timestamp the event, copy a few fields, push to a perf ring buffer. All the heavy lifting (string interning, latency math, aggregation, the dashboard) is in Go on the userspace side. The shape of the data flow: @@ -126,9 +130,14 @@ The shape of the data flow: The kernel ships a C library called libbpf that handles loading the program, attaching it to hooks, managing maps, and reading the ring buffer. There are two well-known ways to drive that from Go: +=> https://github.com/libbpf/libbpf libbpf — the upstream C library + * libbpfgo (Aqua Security): a thin cgo wrapper around libbpf. You ship libbpf along with your binary and call into the same C API that `bpftool` and `perf` use. * cilium/ebpf: a from-scratch pure-Go reimplementation of everything libbpf does (ELF parser, BTF resolver, syscall layer, the lot). +=> https://github.com/aquasecurity/libbpfgo libbpfgo — Aqua Security's cgo wrapper around libbpf +=> https://github.com/cilium/ebpf cilium/ebpf — pure-Go reimplementation + I went with libbpfgo specifically because it's a wrapper, not a reimplementation. ## CO-RE — the part that makes the binary actually portable diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index 794863a5..655f6c89 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,16 +1,16 @@ - 2026-05-10T22:41:22+03:00 + 2026-05-10T22:43:40+03:00 foo.zone feed To be in the .zone! gemini://foo.zone/ - 1) Enable repos and install build dependencies. CRB ships zlib-static / glibc-static. + Unveiling I/O Riot NG — Part 2: install and compile once, run everywhere gemini://foo.zone/gemfeed/2026-05-11-unveiling-ior-ng-part-2.gmi - 2026-05-10T22:39:24+03:00 + 2026-05-10T22:43:39+03:00 Paul Buetow aka snonux paul@dev.buetow.org @@ -18,7 +18,7 @@ This is Part 2 of three. Part 1 is the demo-driven tour: what ior looks like, how the dashboard tabs work, how filtering and recording behave. This part is about the installation for Rocky Linux 8 and 9 and, more interestingly, why you only have to do that dance on a single machine: the resulting binary is portable to every other Linux box thanks to CO-RE (Compile Once, Run Everywhere) plus full static linking. Part 3 is the under-the-hood companion (per-event schema, async-syscall caveats, the syscall-coverage probe generator, and post-mortem SQL on the parquet output).
- (or Podman)# Unveiling I/O Riot NG — Part 2: install and compile once, run everywhere
+

Unveiling I/O Riot NG — Part 2: install and compile once, run everywhere



This is Part 2 of three. Part 1 is the demo-driven tour: what ior looks like, how the dashboard tabs work, how filtering and recording behave. This part is about the installation for Rocky Linux 8 and 9 and, more interestingly, why you only have to do that dance on a single machine: the resulting binary is portable to every other Linux box thanks to CO-RE (Compile Once, Run Everywhere) plus full static linking. Part 3 is the under-the-hood companion (per-event schema, async-syscall caveats, the syscall-coverage probe generator, and post-mortem SQL on the parquet output).

@@ -30,6 +30,7 @@

Table of Contents




Installing ior



+Published at 2026-05-10T22:41:23+03:00
+
+Published at 2026-05-10T22:39:24+03:00
+
The short answer: Use Docker (or Podman). One command, no toolchain setup, works from any Docker-capable Linux host with BTF available: