Erik Sipsma

I guess the idea behind Option 3 is that it doesn't make sense to wait for the agent to connect if the VM hasn't even started yet. If the VM...

@samuelkarp Not really. I think it would still be a worthy enhancement to make the various vsock dialing timeouts configurable. There are various tradeoffs between cpu usage and latency that...

Some preliminary thoughts on this in relation to the CNI support being added to Firecracker-containerd: The CNI support for Firecracker-containerd allows VMs as a whole to be spun up in...

Cool, I will likely not have time in the immediate future, but I may give it a shot sometime if no one else has. Good to know it's in scope...

> Is this specific to stargz or for unpulled layers as well. Eg. cache match for merge(image(), ..). Thinking out loud: not sure if a cache match on unpulled non-stargz...

> That would be a container where the snapshots are mounted into and the container creates a write stream out of it Would this mean that the snapshots have to...

Also, while there is risk of this derailing the idea here, I do think it's worth mentioning that a design here could have *a lot* of overlap with a similar...

As mentioned here: https://github.com/dagger/dagger/pull/3749 There's a lot more very important testing we need to do on macos now (around provisioning done by SDKs+engine-session binaries), and it's currently totally manual, which...

`dagger gateway` as described there shouldn't be a public function right? I don't see that users would ever need to call it.

What are the advantages of Option 2? I guess it seems mostly arbitrary to me in terms of UX. If we go with Option 1, we still retain the option...