Live data from Hacker News

Code and Let Live

fly.io

161–170 of 195 posts

Re: Code and Let Live

#161
post #107

I really want to love this, but my experience in the first 20 seconds is unfortunately like some of my other experiences coding against Fly APIs, they're broken. https://sprites.dev/api has this command: $ curl -X POST " https://api.sprites.dev/v1/sprites " \ -H "Authorization: Bearer $SPRITES_TOKEN" \ -d '{"name": "my-sprite"}' which responds with {"error":"name is required"} if you use the request body in the full…

Probably because you didn't include the content type header?

why does an API that only accepts json need me to specify in a header that it’s json.

just assume it’s json. you’re gonna parse and validate it anyway.

Re: Code and Let Live

#162
post #6

I'm really excited about https://sprites.dev/ - it hits two of my favourite problems at once: 1. Developer environment sandboxes. This is a cheap and convenient way to run Claude Code / Codex CLI / etc in YOLO mode in a persistent sandboxed VM with a restricted blast radius if something goes wrong. 2. Sandbox API. Fly now have a product that lets me make a simple JSON API call to run untrusted code in a new sandbox.…

I have found container-use to be super useful for this. https://container-use.com/quickstart BTW Simon, I was super happy when I heard on Theo's podcast that he will be encouraging you to monetise your work more. I'm super appreciative of your work and I'm pretty convinced that the more you profit from it, the better the universe will be!!!

> BTW Simon, I was super happy when I heard on Theo's podcast that he will be encouraging you to monetise your work more.

There goes the neighborhood.

Re: Code and Let Live

#164

> When you start a feature branch on your own, do you create an entirely new development environment to do it? … yes? We have a few wrapper scripts around worktree operations that copy some docker volumes (pg data, bundle cache, etc.) from the base and spins up an entirely new stack on different ports with a host alias. We don’t have to install any deps beyond that because we copied over the ruby gems bundle cache an…

Wait - you have a repository with a dev environment, and now that you want a new feature branch, you’re creating an entirely new dev environment ? Maybe I’ve been isolated from The World for too long, but this sounds … unhealthy.

Not if you want to run multiple agents in parallel…

Re: Code and Let Live

#165
docs.sprites.dev requires authentication? And what about adding /llm.txt? I want Claude Code Web to install the cli and deploy what it is working on in a sprite :)

Re: Code and Let Live

#167
post #161
post #107

Earlier quoted context omitted.

Probably because you didn't include the content type header?

why does an API that only accepts json need me to specify in a header that it’s json. just assume it’s json. you’re gonna parse and validate it anyway.

If it turns out that someone is willing to pay for some other protocol then they just have to hook it up to that MIME type and start serving. It might be possible that they can derive an implementation of that protocol from their data schemas.

If they hardcode JSON such a change would be breaking for their previous users.

Re: Code and Let Live

#168
post #121

This looks great, i've been wanting a dev sandbox that doesn't run the risk of costing a lot if I forget to turn it off. I had a few issues 1. manpath: can't set the locale; make sure $LC_* and $LANG are correct suspect this is due to it inheriting locale from my local machine? easy to get around with some updates to .bashrc 2. the $SHELL environment in my sprite is `/opt/homebrew/bin/fish` I use fish on my local (ma…

Good point about quietly grabbing env vars, we can warn about that on first run. All it's getting are these:

  var envVars []string
    shellEnvVars := []string{
    "BASH_VERSION",
    "ZSH_VERSION",
    "FISH_VERSION",
    "KSH_VERSION",
    "tcsh",
    "SHELL",
  }
It's also reading terminfo. It's not handling absolute paths to shells properly, though.

If you want to skip this, running `sprite exec -tty /bin/bash --login` or similar avoids the magic.

Re: Code and Let Live

#169
post #5
post #2

Like it, a lot. I think the future of software is going to be unimaginably dynamic. Maybe apps will not have statically defined feature sets, they will adjust themselves around what the user wants and the data it has access to. I’m not entirely sure what that looks like yet, but things like this are a step in that direction.

> I think the future of software is going to be unimaginably dynamic. >...I’m not entirely sure what that looks like yet, but things like this are a step in that direction. This made me stop and think for a moment as to what this would look like as well. I'm having trouble finding it, but I think there was a post by Joe Armstrong (of Erlang) that talked about globally (as in across system boundaries, not global as in…

Not sure if I've read such an article, but it would be a reasonable next step from the globally addressable processes of the BEAM VM.

As I understand it Unison tries to do something like that but that might be wrong.

https://www.unison-lang.org/

Re: Code and Let Live

#170
I'd really love a locally hostable limited version of this, so I can do some quick messing around before switching to the cloud version for long term usage. It cannot be too hard to spin up an API compatible version that just uses the local device + 20GB or something right?
Post reply on HN