This rules out some extremely useful sparse memory tricks you can pull with massive mmaps that only ever get partially accessed (in unpredictable patterns).
Zscaler enrages me with their use of the term "zero trust" in marketing, because due to their MitM-ing of TLS, they become a single-point-of-interception for all your organisation's traffic. "100%-trust" would better describe it for me, as you have to have 100% trust of Zscaler and anyone who has admin access to your organisation's Zscaler account.
There are very few pieces of free software that don't lean very heavily on top of a mountain of other free software that make it possible, and I think the author would be surprised how much of that was written by people who strongly disagreed with his worldview and considered him a "bad guy".
See also the "lite assertions" mode @ https://gcc.gnu.org/wiki/LibstdcxxDebugMode for glibc, however these are less well documented and it's less clear what performance impact these measures are expected to have.
1. The main reason I want to use otel is so I can have one sidecar for my observability, not three, each with subtly different quirks and expectations. (also the associated collection/aggregation infrastructure)
2. I honestly think the main reason otel appears so complex is the existing resources that attempt to explain the various concepts around it do a poor job and are very hand-wavey. You know the main thing that made otel "click" for me? Reading the protobuf specs. Literally nothing else explained succinctly the relationships between the different types of structure and what the possibilities with each were.
I'm currently using pwndbg, which is really just a few python enhancements to the gdb cli, mainly focused on developing exploits, hence the name. It's good enough for me, for now.
Something I've realized about gdb in general is it gets a lot better once you figure out the python api and use it to ease your repetitive tasks.