 Great. So let's talk about Tracy, Tetragon and Falco. How are they different? Which one is better? Bad news? Neither. It depends on your use cases. Let's see what's unique about each tool. Falco is an intrusion detection system. It has an advanced and configurable Detection rule engine and it has lots of predefined rules, which is exactly what you would expect from an IDS Tracy collects tons of different events, tons more than anybody else and Tracy's unique capability is in its data collection for forensics. If you want to collect memory network files, CBPF code It does that for you. Tetragon is a low-level programmable tool kit. So you get to decide what you want to get from the kernel. It's super powerful. It also has kernel level actions that you don't get with the other tools. So what kind of events do we get? For Falco, it's mostly Cisco events and it has others, but it doesn't matter. It has trace tracing, trace point events, but they're not the same as the EBPF trace point events. You can ignore those. Tracy has many different types of events. Cisco events, network events, security events, LSM events, container events, etc. Though the LSM events are not really EBPF-hook-based LSM events that use K-Propes for that. Tetragon has dedicated process events enabled by default and it also has a bunch of other events for the tracing policy program, trace point K-Propes and U-Propes events. These are the kind of event types you can program. You define the YAML policy and you select the hooks that you want to install. All three tools rely on BTF and I'm pretty sure everybody knows what that is and what it has to do with portable EBPF programs. There's a way to make it work with 4.x kernels, but usually if you start with kernels 5.4, which you get with Ubuntu 2004, you'll be good with Tracy and Tetragon. For Falco, but it's a modern EBPF driver, it has two. It has the legacy EBPF probe and it has a modern probe. The modern probe needs kernel 5.8 because it uses ring buffers, which are awesome, but it's stuck with that version of the kernel. How do these tools use EBPF? Falco has a modern EBPF probe, like I mentioned, and it also has a legacy probe. The modern probe uses new BTF-enabled tracing EBPF programs instead of traditional raw trace points. The great thing about those is that you get direct memory access to the data structures. You don't need to use BPF helpers, so you get faster code and more clean code, more maintainable code. Like I mentioned, Falco's modern EBPF probe uses ring buffers to take advantage of the performance and memory utilization improvements. Tracy has more EBPF hooks than the other two tools, predefined hooks, and it also has the most straightforward EBPF code base. Tracy uses per-event buffers for backward compatibility. Tetragon has dedicated EBPF hooks for the process events and then a whole bunch of generic hooks for trace point K-probe and U-probes because it uses these generic trace point K-probe and U-probe EBPF programs that are configured at runtime based on the policy. Now, in terms of the libraries, Falco uses LibBPF, which is the standard BPF library in the kernel, and it has its own LibScap library for system capture. Tracy uses LibBPF as well. Actually, it's a separate library, but it's a Go wrapper, LibBPF Go. Tetragon uses the pure Go Cilium EBPF library, so if you're in to Go and you need pure Go code without C Go and C Code dependencies, that's the way to go. There are different designs in each tool, and because of that, they use different EBPF hooks. The modern EBPF probe in Falco uses mostly the BTF-enabled roll trace points, like I mentioned, and pretty much nothing else. It has generic hooks for sys-enter and sys-exit. Tracy has a lot of predefined EBPF hooks, roll trace points for sys-enter and sys-exit to collect the basic sys-code information and dedicated roll trace points and K-probe hooks for process life cycle calls, lots of K-probe hooks and security function hooks. Instead of using LSM EBPF hooks, it uses K-probes, so it's kind of cheating, but it provides a lot of hooks there, and Tetragon mostly uses programmable trace points and K-probe hooks to get its job done with the programmable YAML tracing policies, and that's pretty much it.