mnutt

I contributed to this update because I think Sandstorm as a concept, improbably, is more important now than it was a decade ago. Some of the core ideas like aggressive sandboxing and a robust capabilities model were somewhat of a hindrance in the past: sandboxing made it difficult to port large existing OSS projects, and many apps didn’t implement capabilities. Now, agents can easily port OSS apps into Sandstorm, not to mention writing new bespoke applications directly within Sandstorm’s sandboxing. I think agents also make composing applications via capabilities very doable: in addition to each hosted app exposing a UI, it can expose an API in an interoperable shape that other Sandstorm apps can use.

Software is at an inflection point with agents where we have the opportunity to take back control of our apps and data from the large corporations and replace it with software we’ve written ourselves and run ourselves. I’m excited for how Sandstorm can enable this.

In cases where startup time matters and you have a slow disk, bundling can drastically reduce the number of filesystem calls you have to make for large dependency graphs.

I have been playing around with building an Iroh Tunnel Sandstorm app that can connect two Sandstorm instances, and share some capabilities exposed from one Sandstorm instance to the other, as if the capabilities were local. Iroh has been very reliable throughout the process.

WebKit does allow outside contributions, though that example is perhaps not the most illustrative as it is from an Igalia employee. Igalia maintains substantial parts of WebKit and at this point has to be the #2 contributor other than Apple themselves.

I think you could in theory have a similar webkit-based stripped down headless crate that might have a good tradeoff of features, performance, and size.

I have a large rails app that was plagued with slow specs using factory_bot. Associations in factories are especially dangerous given how easy it is to build up big dependency chains. The single largest speedup was noting that nearly every test was in the context of a user and org, and creating a default_user and default_org fixture.

Would be interesting to see a benchmark with the rust binary with successively more “bloat” in the binary to separate out how much of the cold start is app start time vs app transfer time. It would also be useful to have the c++ lambda runtime there too; I expect it probably performs similarly to rust.

Tangent: when you have a lambda returning binary data, it’s pretty painful to have to encode it as base64 just so it can be serialized to json for the runtime. To add insult to injury, the base64 encoding is much more likely put you over the response size limits (6MB normally, 1MB via ALB). The c++ lambda runtime (and maybe rust?) lets you return non-JSON and do whatever you want, as it’s just POSTing to an endpoint within the lambda. So you can return a binary payload and just have your client handle the blob.

Sure, you can only use EC2, not use autoscaling or spot and instead just provision to your highest capacity needs, and not use any other AWS service that relies on dynamo as a dependency.

We still take some steps to mitigate control plane issues in what I consider a reasonable AWS setup (attempt to lock ASGs to prevent scale-down) but I place the control plane disappearing on the same level as the entire region going dark, and just run multi-region.

> we never had any issues, because we didn't depend on calling AWS APIs to continue operating. Things already running continue to run.

I think it was just luck of the draw that the failure happened in this way and not some other way. Even if APIs falling over but EC2 instances remaining up is a slightly more likely failure mode, it means you can't run autoscaling, can't depend on spot instances which in an outage you can lose and can't replace.

Even their transfer rates between AZs _in the same region_ are expensive, given they presumably own the fiber?

This aligns with their “you should be in multiple AZs” sales strategy, because self-hosted and third-party services can’t replicate data between AZs without expensive bandwidth costs, while their own managed services (ElastiCache, RDS, etc) can offer replication between zones for free.

That's amazing, what a great idea.

As a four year old, my child loved playing "the subway game", which is similar to this but just in our heads: I name two subway stations and he tries to think of the fastest route between them. When that is exhausted, we move onto the fewest transfers, the most convoluted routes, the 1968 lines only, etc. There's just something about the NYC subway which really draws kids (and many adults) in.