Location: London, UK / Munich, Germany
Remote: No, hybrid only
Willing to relocate: Maybe
Technologies: Go, C, eBPF, Linux
Résumé/CV: on request
Email: [email protected]
Systems engineer with ten years of experience building performance critical software. The past couple of years I’ve been maintaining the most popular Go library for working with eBPF (used by DataDog, Microsoft, etc.) and have contributed to the Linux network stack, the Go standard library and other high profile open source projects. Before that I built Quicksilver (global distributed db) and Unimog (anycast L4 load balancer) at Cloudflare. In my spare time I’ve dabbled in embedded operating systems, virtual machine monitors and emulators.
I’m self taught, learn by doing and enjoy going deep on a specific subject. After working as a fully remote open source maintainer I’m looking for a small team that values collaborating in person, in a strategic role owning a domain or problem space, with a view to leading a team.
I’m curious about problems that require exceptional performance and / or reliability in areas like power infrastructure, renewable energy, operating AI models at scale, non-LLM AI, hardware.
Around the turn of the century, my dad's good friend and longtime collaborator Allen Ross vanishes from one day to the next, just after they have finished shooting a film about the Mississippi. Years later, my dad returns to the US to find out what happened to his friend.
It's his most personal film for sure, and I remember him going off to the US for weeks and faxing us letters to keep in touch. It's also the one that had him most scared, he took out life insurance before he left because of the people he was looking into.
We ended up with fasthash64 and lookup3 by looking for a fast hash that is easy to port to the restricted subset of C supported by eBPF with minimal changes. https://github.com/rurban/smhasher is a great resource for that.
I would probably choose different, more robust hash functions if I was targeting regular C.
What does tail latency for the Zig pool look like? It seems like any Task that ends up in one of the overflow queues will stay there until at some ring buffer is emptied.
Put another way, during a period of more push than pop some tasks may see a very long delay before being worked on?
There is a fair bit of co-evolution of the Linux BPF verifier and the BPF llvm backend. This means that the verifier is biased to do well on bytecode that is commonly emitted by clang. I can imagine that other programming languages will run into the verifier rejecting their output if it differs to much from common clang output. (There is redbpf which compiles rust to BPF AFAIK, but it still uses llvm. There is also a gcc BPF backend, but I don't have experience with that.) The good news is that Linux upstream is receptive to bug reports!
Seems like the right move from a volunteer run project, what will the future will hold though? Artificial scarcity is always a problem.
On another note, for just 20k$ I can offer you exclusive use of the xxgfzrf.dinglebop.me Public Suffix so that you can keep tracking your users. Please reach out to [email protected] if you are interested.
You're arguing that the majority of people use the term differently than you and are therefore wrong. Sounds like the definition of technobabble to me.
Can you define ready? The functionality of the library is solid, it's based on code we're using in production. We've not committed to a stable API however.
The problem is that different kernel configurations end up changing the layout of important data structures. Basically, you need to change the offsets that the eBPF uses.
There is another proposal that uses BTF to do the fixup at load (not compile) time, but that ends up having it's own complications.
LMDB is not a great fit for something like the WAL, where new data is written at the end, and old data discarded at the start. It leads to fragmentation (especially if WAL entries are larger than a single page).
Systems engineer with ten years of experience building performance critical software. The past couple of years I’ve been maintaining the most popular Go library for working with eBPF (used by DataDog, Microsoft, etc.) and have contributed to the Linux network stack, the Go standard library and other high profile open source projects. Before that I built Quicksilver (global distributed db) and Unimog (anycast L4 load balancer) at Cloudflare. In my spare time I’ve dabbled in embedded operating systems, virtual machine monitors and emulators.
I’m self taught, learn by doing and enjoy going deep on a specific subject. After working as a fully remote open source maintainer I’m looking for a small team that values collaborating in person, in a strategic role owning a domain or problem space, with a view to leading a team.
I’m curious about problems that require exceptional performance and / or reliability in areas like power infrastructure, renewable energy, operating AI models at scale, non-LLM AI, hardware.