nathannaveen

Hey, author here, that is a great catch, thanks for pointing it out! If we are protecting a directory, then only people with access will be able to move the dir, so we are assuming that they don’t move (or rename) the directory maliciously. And, if we aren’t trying to protect the directory, then it doesn’t really mater to our protection whether that directory is moved.

Additionally, we are thinking of evicting the inode associated with the directory from the cache if a directory is moved. Doing this would probably catch a ton of edge cases and make it simpler.

Really cool, but the thing I really appreciate is that you had this towards the top of the GH README: "Built with Codex using GPT-5.4 (Low)."

I am fine with using AI to code something, but I really like it when people are honest about it so that I know what I am looking at.

Personally I generally try to avoid concurrency when writing code with AI since I feel AI makes concurrency unnecessary complex in Golang.

I'm also primarily a Go developer, and I will also defend the language in almost all use cases, but I personally feel that C is the best for writing eBPF. I just feel that you get all of the original functionality with C, and you don't have to hack your way around weird issues that you would encounter when using Go or Rust.

Note that we at Bomfather have our userspace code written in Golang and our eBPF code written in C.

But, either way, this is a really cool solution/idea and could make writing eBPF code a lot easier.

I assume this problem could be solved if we write up what we actually want (like a GH issue) and maybe in the future the guys at Stage could use github issues as part of their PR review?

Personally I like Goodnotes since it is pretty good at searching handwriting.

I've been using GCP...

I love this, but I have also been having a lot of fun with https://www.codingame.com/

Nope! We aren't sponsored nor do we work for Brex. These benefits were useful for us and decided to share them!

Truthfully, there isn't any way to prove that we are going to OSS, but we don't want to throw out a half assed product.

I agree, this isn't an ideal scenario, but we want to release our product when we have a working version.

We love open source, and have been working on open source for years now. https://github.com/nathannaveen.

Additionally, we have already open sourced a security tool that we were building before hand https://github.com/bomfather/minefield.

This product is intended to be open source. We are currently building it out, but we are planning to open source it in spring 2026. Thanks for asking!