EBPF allows you to access static tracepoints that are defined in many runtime, and can be used to capture information about the state of the runtime.
Since most VM’s/runtimes allow monkey patching you can usually get to the same level of information without using EBPF. We plan to add support for this in Pixie in the future and provide a seamless experience regardless of what underlying tracing technology is used.
Lots of good stuff from Brendan Gregg here: http://www.brendangregg.com/Slides/Velocity2017_BPF_superpow...
To add to what zasgar mentioned, I just wanted to point out that our instrumentation-free approach does apply to JVM and Node/Python applications for many of the traces we gather. For example, we use EBPF to trace protocols like HTTP as the data passes through the kernel. By gathering the data in the kernel, these EBPF tracers are completely language agnostic.
We'll be publishing a blog post on this soon, so please stay tuned. In the meanwhile, this other post (https://docs.pixielabs.ai/tutorials/simple-go-tracing/) gives an idea of how one can use EBPF user-space probes to trace applications and system libraries.
At Pixie, we are building a new type of data system that can deal with the data volume that we collect and process. We have AI/ML models to help classify traffic and make analysis easier. Over the next few weeks, we will release some blog posts that will discuss how this works.
How is this any worse than downloading a random tarball and running a makefile blindly or installing a deb with god knows what pre or post scripts exist.
If youre that concerned download it and read the script.
It's possible to detect the use of curl|bash and serve different content accordingly . This adds a burden to to the person checking it trying to make sure that any trickery has been accounted for and that you're actually getting a non-malicious installer.
Aside from that, I don't want scripts shitting files all over my file system - I am firmly of the opinion that software installation should be handled in the package manager so it can be cleanly removed later on, upgraded, and so on using the standard tools.
I also see curl|bash as a red flag because it indicates that either they don't have the skill required to build a deb/rpm/etc. package, or they simply don't care to do so - which I feel indicates they have a lazy or uncaring attitude towards software quality and craftsmanship. This is less of a red flag if they say something "debian/ubuntu users download .deb here [link], everyone else please use curl|bash" to limit the variety of package management systems they have to support, but still concerning in my opinion.
 https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... and related discussion https://news.ycombinator.com/item?id=17636032
Getting people to use your junk is more important than doing it "The Right Way".
Word. One of the things I love about Linux is that the prevalence of package management as a defining feature of a distribution is that it's almost always the case that application files are pretty well organized according to a standard (my home directories are a mess, but stuff outside is mostly pristine). Even things that aren't quite up to par you can at least clean up by just uninstalling the package--not perfect, but it generally does work.
The various companies that couldn't be arsed to fit their shit inside an RPM or DEB (not universal, but most other systems will have a functional enough means of converting a DEB or RPM until something gets popular enough that the community repackages it), or nowadays Flatpack, or even Docker (Docker has its own set of issues, but it's a decent enough isolation mechanism, certainly for filesystem stuff) are slowly re-creating Windows' mess of infinity different install/uninstall systems, all broken in their own unique small ways, and are happy to just yeet everything they need over the root directory (ah, the joys of driver installers designed by electrical engineers), are a plague on the modern Linux ecosystem.
"curl | bash" nonsense doesn't even make your installer distro-agnostic anyway--it just means that you'll slowly uncover the incompatibilities over time. Oh, your devs all use OS X, and weren't aware that BSD-lineage and GNU core utils don't all act the same, or are even entirely different, and didn't account for that? You've never encountered differences between FS layouts and your script falls over and dies because it relies on everything looking exactly like the build environment? Cool, you gotta reinvent the wheel now, and will probably do so poorly.
My fav example was a former coworker who loved to spout the adage "____ is a security company, and doing things securely is our top priority" in response to many security-related questions, but was also responsible for a set of instructions that had a "curl -k https://example.com/thing.sh | bash" line. Said engineer justified this with the rationale that the end users they worked with often had borked environments with ancient broken OpenSSL installations (or TLS intercept proxies not properly configured in Linux machines, whatever, some half-assed reason--I assure you that the download server certificates validity was not an issue), and lacked the expertise to fix them, so in the interest of expediency, they took a shortcut and didn't even bother to mark it as a problem to fix later. Our industry never ceases to impress me.