I'm at Meta now but I was at Google as well.
I really enjoy contrasting the two toolchains and where they rise and fall short of each other.
I must say the debugging experience at Meta has been spectacular.
I liked the way CitC exposed Snapshots and easy to make projects.
(+ A bunch of other dozen opinions)
I was also at Amazon circa 2011 and it's funny to think about the experience back then.
I remember i toiled to get Eclipse CDT to work whereas everyone else worked without any language intellisense.
The work paid off though and I was able to drop P95 of the real time service I was on by 50% with the aided code intelligence + hooking it into callgrind.
Interesting. A couple of questions:
- How young are the kids?
- How do they behave, especially with essentials like eating and sleeping habits?
- Could you carve out a morning and/or evening routine for yourself?
- How much outside help could you rely on (grandparents nearby, lovely neighbours...)?
My kids now are 7,5,2.
They were obviously younger when I was doing it.
2 years was during COVID so I never really had to travel for classes which really saved time.
I did most of the coding and ideation on either paternity leave or holidays. Evenings were often running smaller experiments or eventually endless iteration of a paper.
My wife was great and helped me focus usually 8-11pm most nights and some weekends 1-4pm.
We don't live nearby any family and friends were not much help.
* 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?
reply