chalk icon indicating copy to clipboard operation
chalk copied to clipboard

[objective] Platform Coverage

Open viega opened this issue 9 months ago • 0 comments

Today, we've focused on the platforms that are most common to the pain points we've heard in our initial investigations, namely production systems that are predominantly Linux based backend workloads, running on amd64 or arm64 platforms. We've also found a "quick and dirty" way to support MacOS, but more intended to facilitate development, since many of us use the OS.

Certainly, we know from the enthusiastic responses and asks we've gotten as we've previewed Chalk, that people would deeply benefit from having the same kind of observability in plenty of other environments. That includes both basic marking (and extraction) on other platforms, but also includes the ability to collect environmental data at runtime, where doing so performantly and safely is feasible.

For instance:

  1. While the current platform can be made to work with serverless, we would like to do a lot more to ensure seamless integration with a variety of environments.
  2. We're still seeing some interest in Windows support, both for being able to handle PE binaries (particularly for .NET), and for being able to do runtime chalk stuff in those environments.
  3. We've heard from developers that there would be a lot of value in being able to bring chalk capabilities into the browser. We have done some work to figure out how we'd approach marking and extraction, but haven't really done much toward this yet.
  4. Even if just for the technical challenge, we'd love first class support for OS X; we have a solution that works well enough, but it should properly mark the binary; instead, it (mostly transparently) ensures the mark and the binary in sync. This is because OS X is very particular around binary integrity, which we appreciate. We should be playing by the OS's rules to do it the "right" way.
  5. We've had people express interest in mobile architectures and runtime environments that aren't "always on".

One challenge in some of these scenarios is that the architecture pretty deeply embeds a "posix" assumption. Perhaps that's not too bad, as Windows is the big outlier these days, and WSL2 is probably is a fairly achievable target without an ungainly amount of work.

For this objective, we currently have a preference for production usage, over environments that are more user-centric.

viega avatar Oct 02 '23 17:10 viega