I ran into a similar situation a couple of years ago. It wasn't at the scale you describe, but it was an absurd number of requests for a ~80 MB software installer. I ended up redirecting the offending requests to a file named "please-stop.txt" that contained a short note explaining what was happening and asking them to stop. A short time later they did.
Those tools either don't ship with, or exist in wildly different forms on Windows. It's particularly bad for curl, which might be the real curl.se curl or Microsoft's confusingly-named Powershell alias.
I could definitely see using this in a cross-platform build or installation environment.
Windows and *nix systems are often used for very different things so I don't understand why there would be need for some kind of universal superbinary. And thanks to WSL you can already get GNU coretools running in Windows anyways.
I lead a large-ish open source software project. We have developers that need to build on Linux, macOS, and Windows. It's useful to be able to get everyone bootstrapped with as few steps as possible and with as few dependencies as possible. For our uses CMake works well as a universal superbinary, but I'm always on the lookout for tools that can reduce developer friction.
For us (Wireshark) the difficulty wasn't with our own codebase, but with getting our dependencies ported over. Most libraries built just fine, but some strongly assumed that "Windows" meant "x86".
It's not just Windows, either. Many libraries (particularly ones that use Autotools) are absolutely blind to the notion that you might want a universal binary on macOS.
When we ported OpenJDK to macOS, I ended up producing a universal binary by having the Makefile run itself to produce HotSpot twice, and then gluing them together with `lipo` afterwards. There isn't really a better way when the actual project configurations are different.
IIRC it was eventually removed because nobody else needed to do such a thing so it was hard to maintain.
Sure. How else would you build a universal binary then? Given the low-level nature of the language not many tasks can be usefully shared between different architectures.
For plain C/C++ you can just pass `-arch x86_64 -arch arm64` to clang. CMake takes care of this for you if you specify `CMAKE_OSX_ARCHITECTURES=x86_64;arm64` and IIRC Meson has similar functionality.
Clang is natively a cross-compiler. Pass in --sysroot and a corresponding valid sysroot tree for any micro architecture/platform (arm-eabi, macOS, Windows MSVC, PowerPC, Alpine Linux with musl, you name it) and Clang will happily retarget the binary to the correct target platform.
I assume this is faster than doing two separate builds, because it can skip certain steps of the complier pipeline, and only the items that are arch specific (codegen, probably others) are done twice?
How much work does clang have to do for this sort of thing (as opposed to llvm). Hypothetically could we start distributing programs in llvm ir, and compile that locally to ARM, x86, risc-v, or whatever else?
I mean, no, that’s silly, right? But it would be kind of neat…
There's also 13-W3: DB shell, 13 pins, 3 of them coax: https://en.wikipedia.org/wiki/DB13W3. They were used for high-end workstation video back in the day.
The One Weird Trick I learned was to to get a company attorney to write a professional opinion letter saying that you are indeed authorized to get a cert on behalf of your company.
You might try passing `--modern-bpf` to sysdig. It has traditionally captured syscalls using a kernel module, and it sounds like that's where your errors are coming from. Newer versions have added eBPF support, which doesn't require a kmod but you have to pass in the `--modern-bpf` flag.
The tools are similar in many ways, but Stratoshark shares Wireshark's dissection, filtering, and UI code, which provides a more low-level details and a free-form filtering language. Stratoshark is currently limited to capture on Linux (we're hoping to expand to macOS and Windows in the future) and the UI runs on all three platforms. There's an enhancement request[1] to add Procmon file support but I haven't had a chance to investigate what that might require.
It uses Falco libs[1] underneath, which supports capture using eBPF or a kmod. I work with the Falco libs team and they go to great lengths to minimize overhead.
Right now the UI runs on Windows, macOS, and Linux but you can only capture system calls on Linux via Falco libs[1]. Expanding local capture to include macOS and Windows is definitely something we'd love to do!
For macOS you all should look into integrating with the Endpoint Security API. It also provides larger subset of events than just syscalls. You can see them all with `eslogger --list-events`.
Awesome! Thanks for your work on this and everything else.
Once you add capture on macOS with something like dtrace, could you concievably capture a system call inside Docker on macOS and watch it trickle down through the linux hypervisor and then to the host darwin kernel and back?
How does it conceptually track the handoff of system calls between hypervisors/VMs/containers/etc?
In this case you would presumably have a capture file that contained syscall events at both the macOS boundary and at the Linux VM boundary. At the present time it would be like capturing traffic on either side of a firewall and loading it into Wireshark (which is something people do!) You'd have to correlate the events visually/manually but adding an automatic correlation feature is well within the realm of possibility.
Yeah I was imagining something like the TLS session tracing feature in Wireshark that lets you see all the packets related to a single TLS connection.
I currently struggle debugging opaque containers and VMs that run lots of concurrent async jobs, having some kind of tool to trace and group syscalls through the stack would be amazing.
