Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design and Implementation of Sprites

fly.io

Post reply on HN
Print view View original

61–70 of 111 posts

Re: Design and Implementation of Sprites

#61

Post by mrkurt »

raro11 wrote: post #13

Tried it. Docker wasn't preinstalled so asked Claude to do it and make sure it's running (supervisord or the likes isn't preinstalled). It neatly did so and "registered" it as a sprite service. Then I exited my session, waiting for the sprite to go idle, but I don't think it ever does.. Still have it active. Don't know how to idle it. Can't tell for sure if this means I'm losing credits as there is no billing usage s…

Ok so, "running" sprite status has had some cache consistency issues. You're not being charged for idle sprites, but they may show as "running" even when you're not using them. The UX has improved, and it reliably shows what you expect. Some of the existing sprites need an environment upgrade, but you'll see those improve over the next few days.

Re: Design and Implementation of Sprites

#62

Post by tomjen3 »

I was reading through the documentation and it seems like these are writing directly to storage not on the machine where the sprite lives? That makes me worry for how slow the storage is. npm install writes a lot of files.

Re: Design and Implementation of Sprites

#63

Post by mrkurt »

tomjen3 wrote: post #62

I was reading through the documentation and it seems like these are writing directly to storage not on the machine where the sprite lives? That makes me worry for how slow the storage is. npm install writes a lot of files.

It's tiered, they have local nvme that gets written back to object storage.

npm install hasn't bothered me, but I know of people with massive npm issues that would like faster first installs. Fortunately, it's incrementally quicker after that.

The storage performs pretty well for running claude + my dev. It'll improve immensely in the next few months, though. We should be able to get near native NVMe speeds for the working storage set on reads/writes/flush/fua.

Re: Design and Implementation of Sprites

#65

Post by MrOrelliOReilly »

tptacek wrote: post #7
MrOrelliOReilly wrote: post #5

I appreciate the Fly.io team’s enthusiasm and am optimistic this will mature into a product I’d pay for, but my initial impression was of a lack of polish. Documentation is sparse, or not even available? The API docs don’t tell you much about the service itself, and a Google search for docs returns an inaccessible website as the first result ( https://docs.sprites.dev ). Blog posts and forum threads and Claude skills…

You're not wrong. The documentation actually had a hallucinated link to an Anthropic dependency in it when we shipped. Right now the attitude is mostly "if we have to document it extensively, we're doing something wrong". It's been in the works for awhile , with a small team, and we're just getting it out there right now. I've been needling Kurt for several months now that if we wait until it's polished enough that w…

Appreciate your perspective and totally understand that at some point you just have to ship it! From the outside it looks like a bit less time on XYZ feature and bit more time on marketing polish might have been a good call. But can only speculate what the trade offs were internally. Best of luck maturing the product!

Re: Design and Implementation of Sprites

#66

Post by akrauss »

tptacek wrote: post #29
panarky wrote: post #25

Earlier quoted context omitted.

There's no way to stop sprites from the CLI. Supposedly they auto-stop when inactive. But I've tried multiple times and they don't stop, and it's not just Docker that prevents them from stopping. I created a new sprite and installed ffmpeg. Then exited. Next day I run `sprite ls` and it's been running continuously for 23 hours. No way to tell if I'm being billed for it or not. And the per-hour pricing is extremely ex…

Sprites are active when: * They're servicing an incoming HTTP request. * You're interacting with a console. They're hair-trigger inactive otherwise. They don't bill CPU unless they're active. The idea is that there isn't really any uncertainty about when it's running; when you stop interacting with it it stops metering. This is a new shape for a cloud computing thingy and there'll be snags this week with it, but we d…

> Sprites are active when: * They're servicing an incoming HTTP request. * You're interacting with a console.

They are advocated as Linux machines. How about daemons then, or cron jobs? What semantics can we expect from them?

Re: Design and Implementation of Sprites

#67

Post by vardump »

Lerc wrote: post #57
pugworthy wrote: post #34

Earlier quoted context omitted.

This is immediately what popped into my head, and I clicked the link thinking it was going to be some old-school game dev content.

Regardless of the usage of the term Sprite, the real measure of how appropriate it is to use the term for something else is how many people get confused in this manner. I can't really tell what the average reader would think because my background is in game development, so my view is not representative. I think people can get bogged down in the technical weeds over what a sprite is in graphics. Historically it starte…

Most Android devices have hardware that's capable of rather interesting version of hardware sprites. Hardware real-time compositing with scaling and colorspace conversions.

Re: Design and Implementation of Sprites

#69

Post by MildlySerious »

boundlessdreamz wrote: post #31

Is there a way to copy files to/from the sprite? Couldn't see an option for that in the CLI

I would love to just mount a directory via SFTP, so I can use my IDE alongside the far-away Claude. That would put this in the realm of daily use for development.

Re: Design and Implementation of Sprites

#70

Post by aostiles »

boundlessdreamz wrote: post #31

Is there a way to copy files to/from the sprite? Couldn't see an option for that in the CLI

I was trying to copy a directory and used:

Pull from sprite to local: sprite exec -s my-sprite sh -c "tar -czf - /home/sprite/" | tar -xzf - -C ./

Push from local to sprite: COPYFILE_DISABLE=1 tar -czf - | sprite exec -s my-sprite sh -c "tar -xzf - -C /home/sprite/"

Post reply on HN