Mike Dame

Hi @YatinChachra, did you run `make build`? That should generate the compiled `.o` files

https://github.com/open-telemetry/opentelemetry-go-instrumentation/pull/695 I’m not really in favor of this without a really strong reason due to the complications that binary files create with Git. I don’t think that is worth the...

I meant a make task to run go generate in the module cache. Which is not pretty, but I would like us to look into other ways to make this...

I’m saying we should release those files, but I don’t think publishing them in a Git commit is the best way to do that. Are there other (non eBPF) Go...

@MrAlias the post-curation idea is really interesting. That seems like the safest compromise and the pattern already exists for protobuf. I think that's my favorite option, and we could even...

The problem I see with the Go proxy solution is it doesn't support custom Probes (outside our repo), and makes it tougher for us to do a contrib-style repo. I...

Another suggestion from [ebpf slack](https://cilium.slack.com/archives/CKC55JL8L/p1730498226979079?thread_ts=1730324684.565339&cid=CKC55JL8L) was to use Git LFS, which from a quick search looks like it should be compatible with Go modules. I don't know if that would...

> It looks like using Git LFS will mean all modules that take this one as a dependency will need to have it installed and configured in their development environments:...

I also had an idea for a proposal we could make to the Cilium libraries to support runtime object storage: The compiled object bytes aren’t actually a build dependency, they’re...

More updates from the slack thread: * We should make sure we're using `llvm-strip` to reduce the size of our .o files * Cilium already supports direct loading instead of...