General

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: 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.

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.

SDCC

Install from distribution repositories but you need at least version 3.7.0.

Source code is available at  http://sdcc.sourceforge.net/ .

When building you may want to disable some of the supported MCUs.

 

stm8-bin utils – get from https://stm8-binutils-gdb.sourceforge.io/

SPL Patches – get from https://github.com/gicking/STM8-SPL_SDCC_patch

Get the SPL for your device from st.com:

– STM8S/A: “STSW-STM8069”
– STM8L10x: “STSW-STM8012”
– STM8L15x-16x-05x-AL31-L: “STSW-STM8016”
– STM8TL5x: “STSW-STM8030”

How to update makefiles - use examples as base

 

How to debug : need a jtag connection or a serial output for hardcore printf debugging

Hi, Dear Reader!

 

Just to note that we have had an exceptional first year!

More to come …

 

Thank you!

 

Espressif announced on 05/11/2015 the upcoming ESP32 chip:

 

While the specs are impressive a lot of questions a rise :

• Support – Espressif is a small company as far as we knew – would they be able to support both chips in the long term?
• Compatibility with esp8266?  – The new ESP32 will use the RTOS based SDK and most APIs are said to be compatible with the esp8266 SDK.
• Price – The price will be higher than esp8266  but not much higher.

Beta testing program is coming soon.

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