Essays on software development with a focus on quality and production engineering. Mostly.
About two weeks ago, I found a very interesting bug in Bazel’s test output streaming functionality while writing tests for a new feature related to Ctrl+C interrupts. I fixed the bug, wrote a test for it, and… the test itself came back as flaky, which made me find another very subtle bug in the test that needed a one-line fix. This is the story of both. Bazel has a feature known as test output streaming: by default, Bazel captures the outputs (stdout and stderr) of the tests it runs, saves those in local log files, and tells the user where they are when a test fails.
About a month ago, I was benchmarking the impact of a new Bazel feature and I noticed that a test build that should have taken only a few seconds took almost 10 minutes. My Internet connection was flaking out indeed, but something else didn’t seem right. So I looked and found that Bazel was doing network calls within a critical section, and these were the root cause behind the massive slowdown. But how did we get such an obvious no-no into the codebase? Read on to see how this happened and how gnarly it was to fix!
The pkgsrc package database, which by default lives in /var/db/pkg/, should not be there. Instead, it should be under /usr/pkg/libdata/pkgdb/. The same applies to FreeBSD's and OpenBSD's ports and also Debian's dpkg, but I'll focus on pkgsrc because it's the system I know best. Let's see why the current default is suboptimal and why libdata is a good alternative.
The scripts that live under /etc/rc.d/ in FreeBSD, NetBSD, and OpenBSD are in the wrong place. They all should live in /libexec/rc.d/ because they are code, not configuration. Let's look at the history of these systems to see how we got here, why this is problematic, and how things would look like in a better world.
In the previous post, we saw how .d directories permit programmatic edits to system-wide configuration with ease. But this same concept can be applied to other kinds of tracking. Let's dive into a few examples ranging from desktop menu entries to the package manager's database itself.
Have you ever wondered why an increasing number of programs are configured by placing small files in .d directories instead of by just editing a single file? Have you ever wondered why these .d directories seem to proliferate in Linux installations? Read on to understand what these are and why they are useful.
[This post in Spanish to target the Spanish student audience.] La semana pasada nos despedimos de un estudiante de tercer año de carrera que pasó el verano con nosotros haciendo una internship en el equipo de Bazel. Este hecho me hizo pensar en que es el mejor momento de repasar qué son los internships. Mi objetivo es intentar convencerte, si eres un estudiante de carrera, máster, o doctorado, de que son una opción muy interesante y asequible para mejorar tus conocimientos y crecer en el mundo laboral.