* Automatic spin-down scale-to-zero, so you're not paying for it when it's not in use.
If you're using these like we are internally, you've got like 2 dozen of them sitting around in the background sleeping. They're BIC disposable computers. "When in doubt just make another one."
That's roughly what Cloudflare containers are right? (with migrations being the checkpoints?). Cloudflare containers are also nearly instant and have scale-to-zero pricing. The only difference here is the CLI?
Your pricing looks competitive on compute but roughly 4-5 times more expensive on memory and double on storage.
"Containers" are that, and fast, in part because they share kernels, so there's no serious rebooting happening. But the consequence of that design is you share a kernel with untrusted cotenants.
And then there's just the idea of being able to pull these out of the sky literally whenever you want one. If you want to try something new out real quick, it makes no sense to figure out which of your existing Sprites to use. Just make a new one. If you're a little OCD, like I am, every once in awhile you can go prune, if you really care.
The post says "hardware isolated" but below in the sandbox it says firecracker, which I thought were supposed to be a secure way to run containers from multiple tenants on a single host. Also I thought Fly machines were already using firecracker.
I'm having trouble understanding the difference to Fly machines. If you spin up a Debian container on a machine with a persistent volume, doesn't that have everything this does? Is this about providing a layer of useful configuration/management software on top?
Will you have higher tier pricing plans in the future? I don't see a way to sleep them (if you mean other than idle), and the max plan has 10 running concurrently
something that isn’t clear to me: what’s the billing when i’m not actively using a sprite? does that go to zero as well, or am i still being billed for storage?
If it's similar to cloudflare, then it should be usage based. That is you only pay for what is active. (ie: if you are running a task that is waiting on network for 1 hour, you don't pay for cpu but your app is loaded and you are paying for memory). So if your app is dormant (not using cpu or memory), you only pay for the storage you are using.
yeah reading further into the docs it looks like that’s the model. storage is pretty cheap, $.00068/gb-hr, so a 100GB disk runs you about 1.6 cents per day.
I wonder the same thing. What’s so different than your own vps and using lxd to create a container. Make two bash aliases and wow you can go in and out quickly and recreate it with one command.
If you have an LXD setup working for your own workloads that's working well for you, that's awesome. Why would we want to talk you out of that? Fundamentally you're getting at the difference between "elastic" cloud services and personal infrastructure. Personal infra is great!
If it helps: Jerome has been working for a couple months on a local, open-source Rust version of Sprites, so you can use the same DX with your own infrastructure. We just think this is the right "shape" for modern sandboxes, wherever you actually run them.
Glad to hear that the coming local version of Sprites will be open-source. I hope there will be some way to financially reward that work, aside from buying Fly services that I likely wouldn't use.
> With this information, the necessity of code-models feels unecessary [sic]. Why trigger the cost for every callsite when we can do-so piecemeal as necessary with the opportunity to use profiles to guide us on which methods to migrate to thunks.
Does the linker have access to the same hotness information that the compiler uses during PGO? Well -- presumably it could, even if it doesn't now. But it would be like a heuristic with a hotness threshold? Do linkers "do" heuristics?
Once the compiler has generated a 32-bit relative jump with an R_X86_64_PLT32 relocation, it’s too late. (A bit surprising for it to be a PLT relocation, but it does make some sense upon reflection, and the linker turns it into a direct call if you’re statically linking.) I think only RISC-V was brave enough to allow potentially size-changing linker relaxation, and incidentally they screwed it up (the bug tracker says “too late to change”, which brings me great sadness given we’re talking about a new platform).
On x86-64 it would probably be easier to point the relative call to a synthesized trampoline that does a 64-bit one, but it seems nobody has bothered thus far. You have to admit that sounds pretty painful.
While at tailscale you built sketch.dev only to actually build this product ? Love it. Ultimate yak shave.
Kind of how like Antithesis was the product inside foundationdb.
Is this just a fancy VPS like digital ocean with, https endpoint, snapshot and restore?
(Same thing goes for exe.dev)
reply