A little while ago, I read (and quite enjoyed) “Learning eBPF” by Liz Rice. “Linux Observability with BPF” David Calavera and Lorenzo Fontana is another, slightly earlier, book on the BPF framework, also published by O’Reilly.
A while back, I looked at the Diamond-Square Algorithm for terrain generation. That is a purely procedural algorithm that only attempts to generate realistic looking landscapes, without trying to model any physical or geological processes. By contrast, we will now look at an algorithm to generate realistic river networks, which is based on a (simplified) model of geological erosion.
The extended Berkeley Packet Filter, or eBPF for short, is a plugin architecture for the Linux kernel. Using eBPF, it is possible to load (short) programs into the kernel at runtime, and have them be executed by the kernel. As the name suggests, the technology started out as a method to build custom filters for network packets, but it has since been extended and become much more general.
Imagine a bunch of wood chips randomly distributed on a surface. Now add an ant, randomly walking around amongst the chips. Whenever it bumps into a chip, the ant picks up the chip; if it bumps into another chip, it drops the one it is carrying and keeps walking.
How will such a system evolve over time?
A tool to display directory entries, sorted by size, together with their cumulative contribution to the total.
After seeing positive references to it on Linux Weekly News and elsewhere, I bought a copy of “Mastering Emacs” by Mickey Petersen.
On 08 April 2024, I drove up to Erie, PA, to see the total eclipse of the sun.
Go is weird. For all its intended (and frequently achieved) simplicity and straightforwardness, I keep being surprised by its rough edges and seemingly arbitrary corner cases. Here is one.
For every function, data type, or other such code artifact, there are two bits of code: the part that defines and implements it, and the one that uses it.
As I have been thinking (here and here) about the proper use and understanding of Go’s interface construct, the question came up, who is actually responsible for writing the interface: the person who defines the data type, or the person who uses it?
I originally prepared this video as a guide for a relative of mine, but then was surprised how well it came out.