wgjordan

More infringing than emulators. De/recompilation projects are pretty clearly 'derivative works' of the original copyrighted program code, even if they require the original ROM in order to extract other assets necessary to compile a fully playable artifact.

The closer analogy would be fan-translation patches, which are also pretty clearly copyright-infringing derivative works though generally tolerated by rights holders.

Companies often encourage (or at least turn a blind eye to) creative derivative works from fan communities, especially if they're non-commercial and aren't cutting into the market share of their own official products enough for them to take notice.

ad hominem.

Pretty much! It's not dynamic memory hotplug or resizing, just dynamic billing. Usage is based on the actual RSS used by the app so you can think of the VM's defined size as just a limit, for both CPU and RAM. This means you don't have to spend time profiling and right-sizing instances to optimize costs, just make your application fast and efficient and don't worry about it!

These are both later-stage detail questions for when this project is further hardened for production workloads, but here's where each of these currently stands:

- Yes, there is a post-restore kernel reseed hook that happens after fork, and just before the trapped listen is continued. It doesn't use the vmgenid driver, it just calls the RNDRESEEDCRNG ioctl, so it would not be compatible with applications that depend on vmgenid notifications to reseed userspace PRNGs.

- In Syzy, the full pruning implementation is deferred for now; at the managed product's current small scale, it can simply eat the tiny overhead costs of un-collected garbage, while the user is only billed for the logical storage space consumed.

Thanks for the kind words!

> I didn't immediately spot the durability contract for volumes -- local NVMe like Fly, or sitting on some underlying system like EBS?

Persistent volumes use local NVMe that continuously syncs to object storage, so a similar architecture to Fly Sprites. It automatically recovers from host failures (with on-demand lazy restore), and you can manually migrate stable members to another region if needed.

I've positioned persistent volumes as an escape hatch for when you need an existing database app running in a VM, or when performance requirements outgrow the built-in replicated SQLite.

Thanks! I tried to make the sandbox-eval stdin interface as simple as possible so you could easily plug it anywhere. The executable docs run an actual full shell in a VM, since they're so fast and cheap to spin up- I hope the example made it clear how to use this feature!