I help where I feel I can help most, and take everything I learn along the road with me.
Before I crossed into open source, I served in Feuerwehr — from Jugendfeuerwehr through Einsatzabteilung. It is where I learned that being useful is a practice, not a credential. Show up. Train. Be the person who makes the hard moment easier for everyone else in the room.
Programming has been the long companion underneath all of that —
eight to ten years of it, mostly alone, mostly at night. Documentation,
source code, portability gaps. How does kqueue compare to
epoll? Why does a libc assumption that holds on Linux
silently break on FreeBSD? These are the questions that pull me in,
and they pull me in deeper than I usually plan for.
A little under a year ago I crossed the threshold from self-taught programmer into public open source contributor. The current road has led me to FreeBSD HPC infrastructure — UCX, OpenMPI, Slurm, PMix, PRRTE — because this is where I feel I can help science the most from where I stand right now.
I run FreeBSD on everything. It started with servers, then became my daily driver. The moment I first read about it I was curious — straight into the handbook, the forums, the mailing list archives. That curiosity has not left.
Most of this happens at night. Quiet hours, careful hands.
FreeBSD as a first-class HPC platform.
FreeBSD has the technical foundation. The kernel is solid, the networking stack is excellent, and the system's design philosophy aligns with the reliability demands of compute clusters. The HPC software ecosystem on top of it is where the gaps live — ports missing, ports outdated, fixes that never made it upstream.
Why it matters
Scientific computing clusters demand stability, predictability, and performance. FreeBSD's design delivers all three — but only if the software stack exists. Right now, researchers who want FreeBSD on their clusters carry their own patches. That should not be necessary.
Where the gaps are
UCX, OpenMPI, PRRTE, PMix, Slurm — the core HPC runtime stack. These tools were written Linux-first, and the glibc assumptions baked into them break silently elsewhere. Portability is not glamorous work, but it is necessary work, and somebody has to do it carefully.
What I am doing about it
Porting, upstreaming, coordinating. Every patch I get upstream is one fewer patch the ports tree has to carry. Every committer relationship I build makes the next submission easier. Slow, methodical work — exactly what the platform needs.
Working through the UCX upstream portability PR — endianness,
CPU set sizing, build-system cleanup. Adopting www/py-pelican
as maintainer and pushing it through review. Auditing
net-mgmt/net-snmp's downstream patches against upstream
master and preparing separate PRs for the bugs the audit uncovered.
Self-hosting a small Forgejo on FreeBSD because the ports work
deserves a home.
kavocado.net is a small constellation of sites.
Each subdomain has one job. The boundaries keep the work readable — patches in one place, writing in another, the self-hosted forge holding the actual source.
Looking for the detailed portfolio?
Contributions, commit history, ticket history, methodology, and contact details are on the portfolio page — the dossier version of all of this.