Questions about Falco

[dthaler]

What Needs To Be Fixed?

In https://github.com/ebpf-io/ebpf.io-website/pull/166, Brendan explains:

Falco is listed as a "major" eBPF project, but clearly it's possible to deploy Falco w/o eBPF, per https://falco.org/blog/choosing-a-driver/.

Since as Daniel explained, the requirement is:

The project must be using eBPF as its underlying core technology, in other words, a project would lose its purpose if the eBPF parts are removed.

Brendan asks whether Falco really belongs on this page, as it appears inconsistent to list Falco and not Calico if the answer is the same for both.

Page(s) Affected

https://ebpf.io/applications

[xmulligan]

Do we know who made the original contribution and we could ask them? I can't seem to find it in the Git history

[dthaler]

https://falco.org/docs/ confirms that Falco as a whole fails the stated requirement that "The project must be using eBPF as its underlying core technology, in other words, a project would lose its purpose if the eBPF parts are removed."

https://falco.org/docs/getting-started/installation/#install-driver uses the term "eBPF probe driver" for the eBPF portion which could conceivably meet the requirement. However there's no evidence I can immediately find for the eBPF probe driver itself to meet the "major" requirement of having more than 50 contributors.

Either way I now believe Brendan is correct that Falco should be removed from the page. (Someone could add the Falco eBPF probe driver to the Emerging section if they could argue it is an "application", but perhaps it's more a "library" like libxdp?)

[dthaler]

@mstemm can you confirm?

[mstemm]

I’m going to work on an answer with https://github.com/leogr and we’ll reply here beginning of next week. Many of our maintainers are in Europe so it’s already the end of their week.

[leogr]

Hi :wave:

Falco core maintainer here. Although I can understand your concern, I would like to highlight that:

• Falco is likely one of the biggest eBPF codebases on the earth, with more than 22k LOCs of manually written eBPF source code
• We have two eBPF probes; the modern one (still experimental, so not yet reported in the official docs) uses CORE and will be embedded in the Falco executable and likely will be the default way to use Falco
• "The project must have more than 50 contributors." should refer to the whole project (what's the point of considering only the eBPF part and ignoring the userspace counterpart?). Anyway, if you think we should count only those contributors that have written eBPF code, let me know, and we will provide you with more detailed metrics.
• The kernel module is maintained for old kernels, but we don't disallow our users to use it wherever they want (or shall we disallow that? :thinking: )
• For most users, eBPF is the only way to deploy Falco, and it would lose its purpose without eBPF (to give an example: for all those who deploy Falco on managed Kubernetes clusters)

Now, considering the importance of Falco for the eBPF community and the above points, I'd argue that your main :point_down: requirement :point_down: may be ambiguous or improper for some relevant eBPF projects:

The project must be using eBPF as its underlying core technology, in other words, a project would lose its purpose if the eBPF parts are removed

Thus, I'd kindly ask you to reconsider if Falco meets your requirement or reconsider the requirement itself since it may involuntarily penalize some significant projects. That being said, the decision is up to you. I will appreciate your effort anyway. :pray:

PS If you need any further information about Falco, let me know.

[borkmann]

@dthaler I think this is resolved as per https://github.com/ebpf-io/ebpf.io-website/pull/399 and the GH issue can therefore be closed w/o further changes needed, correct?

[dthaler]

Agreed