Software

Introduction: A Problem Hiding in Plain Sight

Direct I/O (O_DIRECT) has been a contentious feature in Linux since its introduction. Linus Torvalds famously called it a design “by a deranged monkey on some serious mind-controlling substances” back in 2002. Yet for years, it continued to work—mostly. Applications used it, databases relied on it, and virtual machines benefited from its zero-copy performance.

But something fundamental has changed. As modern software has embraced multi-threading at every level—from applications to filesystems within the kernel itself—a problem that was once manageable has become critical. The truth is stark: with O_DIRECT, there is no way to guarantee that nobody will touch your I/O buffers during the operation.

Introduction

I’ve been working on a new project that required high-performance UDP load balancing with dynamic weight adjustment. Traditional userspace load balancers introduce latency that’s unacceptable for our use case, so I decided to implement a kernel-level solution using eBPF (extended Berkeley Packet Filter).

The result is ebpflb_udp_wrr, an eBPF-based UDP load balancer that distributes incoming UDP traffic to local listeners using a weighted round-robin algorithm.

Why eBPF and XDP?

eBPF has revolutionized how we can extend kernel functionality without writing kernel modules or modifying the kernel source. Combined with XDP (eXpress Data Path), we can process packets at the earliest possible point in the networking stack—right when they arrive at the network interface—minimizing latency.

Introduction: The Illusion of Sequential Execution

When you write code, you naturally think in terms of sequential execution: instruction A happens, then instruction B, then instruction C. This mental model works perfectly—until you start writing concurrent code or working with hardware. Then you discover that modern CPUs, compilers, and memory systems conspire to execute your code in ways you never imagined.

The truth is that sequential consistency is largely an illusion maintained by your compiler and CPU to make programming tractable. But when multiple cores or threads are involved, that illusion breaks down in spectacular and subtle ways.

A Networking Mystery

Over the past two days, I found myself conducting a complete forensic analysis of my network. Something unexpected had changed the IP address of my main host’s bridge0 interface. Given that a critical React Server Components vulnerability had been released (GHSA-fv66-9v8q-g76r), and I had recently deployed several new Docker containers—some with access to the host Docker socket (I know, not ideal)—I immediately suspected a compromise.

The situation felt serious. By sheer luck, changing the bridge interface address cut all network access to my homelab, which at least contained the potential damage. I examined every Docker image on the system, but found nothing suspicious.

The Hardware Testing Challenge

When developing hardware, the challenging phase begins after the prototype is designed and PCBs are manufactured. The easy part—conceptualization and board design—is behind you. What follows is infinitely harder:

• Making boards electrically alive and verifying proper operation with electrical jigs and test equipment
• Programming and validating firmware behavior
• Testing the complete system’s functionality under real-world conditions
• Building the infrastructure—both hardware and software—to support comprehensive testing

For devices communicating via NMEA protocols, this challenge is compounded by the complexity of marine electronics standards and the difficulty of simulating real maritime data streams.

Why ESP32C5?

I’m researching hardware options for an upcoming project, and the ESP32 family appears to be the best fit for our current requirements.

For years, a major drawback of Espressif chips was limited support to 2.4GHz WiFi only. Why does this matter? Having a 2.4GHz device on a WiFi network degrades performance for all other devices, forcing users to set up separate WiFi routers just for 2.4GHz devices. Additionally, the initial configuration proved frustrating—when your phone is on 5GHz, the ESP Touch protocol doesn’t work reliably.

Using Compiler and ELF to Avoid Ifdef and Flags Hell for Selecting Runtime Features

I was digging into redis source recently and i came to realise some lesser know features
of gcc/clang needs some more publicity, so i will write about them here.

The problem: You want to get best of the CPU/Hardware/Features but usual way to do this
is either build for specific hardware or use runtime checks both have drawbacks.
First on a new hardware you need a new build and results in

Vevor 7 in 1 Wifi to Windy and HomeAssistant

For a long time i wanted to install a weather station but since
i have to put it on a roof which is easily accessded by outside
people i needed something on the budget side.

So during a recent Ali promotion i got one - Vevor 7 In 1 WiFi
model.

You need the WiFi version, there non-WiFi version which you can work
with too but you need to have RTL SDR dongles and recode radio data send
from the outdoor unit to the sensor. This post is about the WiFi only.

A Teaser of What to expect from our upcoming WiFi connected 2 channel relay board.

Web UI of the relay board

Main control screen and part of the configuration

Main control screen

Part of the configuration

Schedule editor

Hi,

A simple i2c driver for the Microchip’s TCN75A thermometer – supports up to 8 thermometers. Driver works in one shot mode which is suitable for battery powered operations. The chip is with quite good specs for its price.

Code at github esp_i2c_tcn75a .

Usage:  checkout user/user_main.c for example usage.

Enjoy!

73