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

51–60 of 111 posts

Re: Design and Implementation of Sprites

#51

Post by roywiggins »

adriand wrote: post #11
roywiggins wrote: post #3

I've been having fun with OpenCode's webui in a Sprite, set it up right in Termux and you can vibe code a website with a full backend from your phone. I have a Termux shortcut that sets up a port forward and pops open my web browser to the OpenCode webui. OpenCode can pick up the Sprite skill built into the containers so it can manage the instance itself (mostly setting up and destroying services). Of course you can…

What's the option for iOS? I've tried installing ish and a-shell and can't get the sprites CLI installed on either of them.

Vibe code a client in bash or Python that uses the Sprites HTTP API maybe?

Re: Design and Implementation of Sprites

#52

Post by karmajunkie »

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…

I think the idling feature still needs some work. I created one over the weekend that hasn't idled once, and I've run several tests with sprites that have nothing in them—just `sprite create` and log out, just to see what happens (which unfortunately is nothing, left alone it keeps on running as well.)

I love the idea and most of the execution, I've really enjoyed getting my first sprite configured just the way I want it. It just needs the idling feature to work as advertised before I think I can use it as cost-effectively as it promises.

Re: Design and Implementation of Sprites

#53

Post by karmajunkie »

chrismccord wrote: post #14
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…

We had a bug where some sprites would fail to properly suspend while entering their suspended state. You're not eating into credits so no worries there. We've been rolling out a fix across the fleet today so you should be seeing proper status soon.

This is great news! If we upgraded our sprite already how long should it take to suspend? I noticed the upgrade earlier and installed it but my sprite is still running.

Re: Design and Implementation of Sprites

#54

Post by ssully »

Sounds neat! Also kind of funny, because I already use Fly machines as a bit of a playground for some personal projects and really like it for that purpose. I have minor issues, some of which this blog post directly talks about, but nothing that has held me back.

Also I like a lot of what you get built-in with Fly machines(ex:Grafana). So I am curious how this would fit in my workflow. Maybe Sprites for rapid development and toy projects, and move to a Fly machine when I need something a little more beefy?

Looking forward to checking this out.

Re: Design and Implementation of Sprites

#55

Post by el_nahual »

tptacek wrote: post #46
el_nahual wrote: post #44

Earlier quoted context omitted.

I hate being negative but it sounds like par for the course for fly. Incredible (truly, incredible, world-class) engineers that somehow lack that final 10% of polish/naming/documentation that makes things...well, seriously usable. I remember last time I tried them the bizarre hoops/documentation around database creation. I _think_ they solved that but I remember at the time it felt almost like I was getting looked do…

Naming ? We got naming wrong?

Could not have illustrated the point better if I tried.

Re: Design and Implementation of Sprites

#57

Post by Lerc »

pugworthy wrote: post #34
vardump wrote: post #26

Earlier quoted context omitted.

A graphical object composited just in time in display scanning process. (Or in other words, a graphical object on screen that is not present in a framebuffer of any kind.)

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 started out as mini graphics overlays in hardware. There was a transition period motivated by Amiga documentation to have Sprites and Bobs, to distinguish, and perhaps advertise, the use of the Blitter. When software or Blitter Sprites became nearly ubiquitous, they returned to simply being called Sprites, the fairly rare use of the original form became known as Hardware Sprites. Usually it was only mouse pointers that remained as Hardware Sprites

Obviously the term Hardware Sprites is not strictly a distinguishing label either. They are all controlled by software using hardware with some degree of balance between the two.

Re: Design and Implementation of Sprites

#58

Post by karmajunkie »

karmajunkie wrote: post #53
chrismccord wrote: post #14

Earlier quoted context omitted.

We had a bug where some sprites would fail to properly suspend while entering their suspended state. You're not eating into credits so no worries there. We've been rolling out a fix across the fleet today so you should be seeing proper status soon.

This is great news! If we upgraded our sprite already how long should it take to suspend? I noticed the upgrade earlier and installed it but my sprite is still running.

ahh finally success—a fresh sprite goes to sleep as it should. unfortunately the original one i created doesn't, so I guess I'm going to have to kill that one off.

Re: Design and Implementation of Sprites

#60

Post by senko »

Not sure where to report this, so here goes: something weird's going on with the title setters (from default .bashrc, the 'case' block near the top) when connecting from my Linux box.

Tried with xterm, tilix and ghostty, all of which support the title setter escape sequence locally. For some reason, these get messed up (smells like edge case with escaping) and the result looks like this:

    $ sprite c  ": history-search-backward'
    \]\u@\h\[\]:\[\]\w\[\]\$ '                           ": history-search-forward'sprite@sprite:~$
    "sprite@sprite:~$
I'm guessing y'all use Zsh because that works flawlessly :)
Post reply on HN