Live data from Hacker News

Code and Let Live

fly.io

71–80 of 195 posts

Re: Code and Let Live

#71
post #13

fly.io is doing really good work. I've super enjoyed building our product on their platform. I love fly-replay combined with super fast start-up. I've been thinking a lot about how to run agents (and skills) securely while giving them a lot of powerful capabilities. I recently used their macaroons library to turn arbitrary API keys (e.g. for stripe's API) into macaroons. I route requests for an upstream host (like st…

Did you write up anything about this? Is this off the shelf behavior for Envoy or did you create this API yourself?

I can open source it next week when i get a chance.

Re: Code and Let Live

#72
post #63
post #62

[flagged]

You feel wrong. I would eat a bug before I ran LLM text on our blog. This one thing --- the fact that you can't negate a clause without people claiming an LLM wrote it --- this alone do I place angrily at the feet of AI.

Peoples' writing is influenced by what they read, so such a strong objection to someone suggesting that an LLM might have been involved in the text of a blog post won't fly with me.

Re: Code and Let Live

#73
post #63

Earlier quoted context omitted.

You feel wrong. I would eat a bug before I ran LLM text on our blog. This one thing --- the fact that you can't negate a clause without people claiming an LLM wrote it --- this alone do I place angrily at the feet of AI.

Peoples' writing is influenced by what they read, so such a strong objection to someone suggesting that an LLM might have been involved in the text of a blog post won't fly with me.

Shrug-emoji. I copyedited this post. I get that people don't have a lot of my writing to go off of on HN, it's a real problem I have.

Re: Code and Let Live

#75
It'd cool to create a MCP for this so you can have your agents run persistent code/other agents.

This is a large pain point today if you aren't technical, most of the chat interfaces just let you create frontend only apps.

Re: Code and Let Live

#76
> 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 and we’re using Yarn PnP + “zero installs” for client-side deps.

Re: Code and Let Live

#77
post #66

Earlier quoted context omitted.

I see. Also "containers" always had the option to attach durable storage via bind mounts. I still get confused by the "this isn't containers" but it's kind of similar. Maybe I am just too caught up in semantics. A VPS that is instant to boot, super simple automatic routing and https proxy, with snapshot and durable is a win regardless.

"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…

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?

Re: Code and Let Live

#78

It'd cool to create a MCP for this so you can have your agents run persistent code/other agents. This is a large pain point today if you aren't technical, most of the chat interfaces just let you create frontend only apps.

You can do this now without an MCP, by auth'ing the `sprite` command inside of a Sprite and telling Claude to go document it for you. You can do things like "make me three versions of this feature on three different Sprites so I can compare them". It is spooky how easy it is to teach agents this stuff.

Re: Code and Let Live

#79
post #77
post #66

Earlier quoted context omitted.

"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…

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 d…

Subtle to explain. I'll explain better later this week. For now though, just know: every Sprite is under the hood a KVM VM.

Re: Code and Let Live

#80

On one hand it sounds cool. On the other, I feel like I missed it. Is this just a fancy VPS like digital ocean with, https endpoint, snapshot and restore? (Same thing goes for exe.dev)

Basically endgame VPS. Instant creation, snapshotting, restore. Actually quite impressive even if you don't buy the whole Claude spiel.
Post reply on HN