Linux

Most break reminders rely on a plain clock, so the alarm still fires the instant a fifty minute timer runs out, even if you spent thirty of those minutes away from the desk getting a coffee, because the timer has no way of knowing that you already sat back down. I already wear a smartwatch that vibrates on my wrist whenever I have been sitting too long, which helps, although it tracks the wrong thing, since it watches my wrist rather than my desk, so that a handful of arm movements is enough to convince it that I got up while I am still in the same chair, in front of the same screen. I am also the kind of person who concentrates hard enough to lose track of time entirely, so that eyestrain is usually the first sign I get that I went too far. Because I wanted something that watches the desk instead, I turned to a piece of 2009 e-waste sitting in the corner of it: a Samsung N130 netbook with a single core Intel Atom processor and 1GB of RAM. It runs Void Linux, and it is the same machine that I turned into a basement WiFi router a few months ago. I made it a desk sentinel that checks whether I am really sitting in front of the workstation, counts work time only while I am there, and speaks up once I stay too long. Image credits to: Bananayota, found on Pixabay TL;DR The basic idea: when something moves in the webcam frame, it means I am at the desk. If I stay at the desk too long without a break, the netbook speaks up. An old Samsung N130 netbook running Void Linux works as that desk sentinel. motion watches the built-in webcam and, on every start and stop of movement, writes active or idle into a plain state file. A small Nim daemon reads that file and tracks continuous desk time with a live one line progress bar, so that once the limit is reached, it calls espeak-ng and wall, while an absence under 5 minutes never resets the clock. Nothing is recorded, because the video feed never leaves the netbook and no frame is written to disk. The daemon runs as an unprivileged supervised runit service that costs 0.01% of one core and 2 MB of RAM, since motion is the real cost on this hardware. ...

🧭 Where we left off Welcome back to our technical journey on measuring binary test coverage! In part 4 we introduced funkoverage, a native, high-performance eBPF-based coverage tracer that leverages uprobe_multi to capture function entry events in GNU/Linux with less than 2% overhead. It parses static library dependencies using ldd during installation and maps uprobes to all discovered functions. But there was a big fat elephant in the room: dlopen(). Some of the most complex, modular software in the world — such as web servers with dynamic modules, plugin-based enterprise applications, and multi-protocol databases — load their dependencies at runtime on-the-fly. Because these libraries are not declared in the ELF binary’s DT_NEEDED header, they are invisible to ldd during installation. Today, we are going to chase the dynamic loading ghost, explore how we solved this with an elegant, highly scalable, event-driven eBPF JIT instrumentation strategy, and battle-test it live on standard, unmodified production binaries like Nginx and OpenSSL! ...

🤔 What’s a syscall, anyway? Image credits: Mike Norris via Pexels Every time your program reads a file, writes to a socket, or allocates memory, at some point it has to ask the kernel to actually do it. That ask is a syscall, the narrow, well defined boundary where userspace code crosses into the kernel. write(), read(), open(), mmap(), these aren’t just library functions, they’re the entire vocabulary your program has for talking to the outside world. Everything else, fwrite, Python’s file.write(), std::fs::File, is just a wrapper around this same handful of kernel entry points. ...

🧭 Where we left off Welcome back to our ongoing series on measuring test coverage for binary programs! In part 1 we used Go’s built-in -cover flag — clean and accurate, but only works if you own the source and can recompile. In part 2 we used valgrind and gdb to trace gzip without touching its source. In part 3 we explored Intel PIN, a proper dynamic binary instrumentation framework — powerful, but it came with a ~100MB proprietary C++ SDK and was limited to x86_64. ...