Here there are some notes that I’d like to share with you :-)
From a frozen Telegram photo to the Linux graphics stack
1. The fullscreen photo that froze a laptop It was Sunday morning, I had a fever, and my plans extended no further than tea and feeling sorry for myself; troubleshooting a GPU failure was not on the list. I opened a photo from Telegram Web in Brave and switched it to fullscreen. The display froze. After failed attempts to recover it, I forced the Framework Laptop to restart. A TTY later showed Vulkan selecting my AMD Radeon 780M, followed by two warnings about dynamic-buffer limits whose timestamp placed them more than ten minutes after the next boot began....
The binary I ship is the binary I want to test
This article expands on my OpenSouthCode 2026 talk. I have a slightly awkward question for anyone who collects code coverage in CI: Are you testing the same binary that you ship? For many projects, the honest answer is no. Traditional coverage starts at compile time. Go builds need -cover. GCC uses --coverage, shorthand for -fprofile-arcs -ftest-coverage when compiling and -lgcov when linking. Clang’s LLVM source-based coverage uses -fprofile-instr-generate -fcoverage-mapping. llvm-profdata indexes the raw profile, and llvm-cov creates the report....
Unleashing the power of frame pointers for profiling pt.2 - Writing a basic profiler
In the previous blog about the program execution environment, we introduced the concept of stack unwinding with frame pointers as one of the techniques leveraged for profiling a program. In this blog, we’ll see practically how we can build a basic sampling-based continuous profiler. Since we don’t want the application to necessarily be instrumented, we can use the Linux kernel instrumentation. Thanks to eBPF we’re able to dynamically load and attach the profiler program to specific kernel entry points, limiting the introduced overhead by exchanging data with userspace through eBPF maps....
Unleashing the power of frame pointers pt.1 - The execution environment
Profiling the CPU allows us to analyze the program’s performance, identify bottlenecks, and optimize its efficiency. Have you ever wondered what happens behind the scenes when you run a program and how to account for CPU time for the actual program functions? And even more, how to write such a tool to profile the program? Even though great open-source projects provide continuous profiling with vast support for compiled, JITed, and interpreted, languages, with or without debug info, with or without frame pointers, etc....
How I improved consistency and performance in a Go crawler with retry logics and network tuning
Introduction wfind is a simple web crawler for files and folders in web pages hyerarchies. The goal is basically the same of GNU find for file systems. At the same time it’s inspired by GNU wget, and it merges the find features applied to files and directories exposed as HTML web resources. In this blog we’ll go through the way I improved consistency in this crawler, by implementing retry logics and tuning network and transport in the HTTP client....