It is funny how many people think you have to code your ebpflets in C. It turns out you can use C++, or even Rust or D, just as easily.
I like that some peripheral manufacturers (e.g. Netronome) will compile your ebpflet, in their driver, to the native code of a processor on their hardware, so it doesn't even need to wait to get scheduled onto a kernel thread to start running.
I have no gripe with Cilium being marketed in this way, it's good and I think eBPF deserves more recognition, it's an amazing piece of tehcnology and opens up even more possibilities for people building things using Linux systems as blocks (and for regurlar sysadmins too).
But in the projects section it says:
> * In order to be listed as a major project as opposed to an emerging project, the project must have more than 50 contributors
Come on! Is, say, 40 a bad number? eBPF is still very much developing, and setting such arbitrary limits makes little sense.
This site is kind of an ad/content marketing for Cilium[0], a container networking solution for container orchestrators (most notably Kubernetes).
But then again Cilium's main differentiator is utilizing the advanced support for eBPF[1] in the kernel and it was launched by a Thomas Graf (a kernel developer)[2], so it feels appropriate. From the QCon description:
> Thomas Graf is Co-Founder & CTO at Covalent and creator of the Cilium project. Before this, Thomas has been a Linux kernel developer at Red Hat for many years. Over the more than 15 years working on the Linux kernel, Thomas was involved in a variety of networking and security subsystems. For the past couple of years, Thomas has been involved in the development of BPF and XDP.
Nice to see kernel developers getting something for their thankless hard work. I haven't given Cilium a try on my own k8s cluster, but I hope to give it a spin soon. I don't think I need the majority of the features but the inter-pod communication speedup and cluster-mesh features are attractive to me.
What is eBPF?
The Linux kernel has always been an ideal place to implement monitoring/observability, networking, and security. Unfortunately this was often impractical as it required changing kernel source code or loading kernel modules, and resulted in layers of abstractions stacked on top of each other. eBPF is a revolutionary technology that can run sandboxed programs in the Linux kernel without changing kernel source code or loading kernel modules. By making the Linux kernel programmable, infrastructure software can leverage existing layers, making them more intelligent and feature-rich without continuing to add additional layers of complexity to the system.
eBPF has resulted in the development of a completely new generation of tooling in areas such as networking, security, application profiling/tracing and performance troubleshooting that no longer rely on existing kernel functionality but instead actively reprogram runtime behavior without compromising execution efficiency or safety.
What is eBPF.io?
eBPF.io is a place for everybody to learn and collaborate on the topic of eBPF. eBPF is an open community and everybody can particpate and share. Whether you want to read a first introduction to eBPF, find further reading material or make your first steps to becoming contributors to major eBPF projects, eBPF.io will help you along the way.
If the title is bad, you can use the subtitle. and if that fails, a sentence of the article without cherry picking too much (it's a fuzzy rule). (And sometimes the mods revert the changes anyway.) I like:
> eBPF is a revolutionary technology that can run sandboxed programs in the Linux kernel without changing kernel source code or loading kernel modules.
but it is too long, a shortened version to 80 characters is
eBPF: run sandboxed programs in the Linux kernel without changing kernel source
I like that some peripheral manufacturers (e.g. Netronome) will compile your ebpflet, in their driver, to the native code of a processor on their hardware, so it doesn't even need to wait to get scheduled onto a kernel thread to start running.