Yup, this is usually the case in pig butchering operations iirc.
283 karma · joined January 6, 2016
The other day I refused to fire it up for him and he had a full meltdown. I told my wife I had never seen product market fit like that before.
It is a little harder with something like a game to maintain motivation and go for perfection when you know your audience is an audience of one but it’s also a relief to just worry about the things he cares about (trains and firetrucks).
I also miss there being something intellectually challenging to a side project but that probably means I just need to learn a real game engine after this.
I’m working on https://coasts.dev.
I’ve been thinking a lot about the light vm side lately but it’s not an area we are going to attack ourselves. I think there’s a really good pairing between what we’re working on.
I wanna hear how they compose naturally.
So the name "hot" is a bit misleading. The containers don't actually stay alive through the switch. What happens is we do the umount -l /workspace, mount --bind, mount --make-rshared sequence first, and then we run docker compose up --force-recreate. Force-recreate skips compose down (which would tear down the network, named volumes, everything) and just swaps the container processes in place. The old containers and their file watchers are killed and new ones start up.
By the time the new container processes start, /workspace already points at the new worktree so all their file handles are fresh and correct. There's no window where a watcher could be writing to stale paths because the old processes are just gone.
I was pretty afraid of this at first too but it turns out the force-recreate sidesteps the whole problem.
One cool thing we do is we have the docs and semantic search of our docs baked into the CLI, so if the agents get lost they can usually figure things out kind of quickly by searching the docs via the cli.
Also we have a little section our agent.md and claude.md,I’m not sure how well it works without that.
Well fortunately it's the name of a local observability ui and not the actual product. We'll change it if it becomes a problem.
Alternatively, you can setup the Coast to install MCP services in the containers. There are some cases around specific logging or db MCP's where this might make sense.
>Would love to see this support stdio-to-HTTP bridging so local MCP servers can be exposed as remote ones without rewriting them.
Are you saying if you exposed the MCP service in the Coast and hosted it remotely you could expose back the MCP service remotely? That's actually a sort of interesting idea. Right now, the agents basically need to exec the mcp calls if they are running host-side and need to call an inner mcp. I hadn't considered the case of proxying the stdout to http. I'll think about how best to implement that!
I think we're focused on the other end of the spectrum. Folks who like docker and have a good docker setup but want to have parallel runtimes. Anyway, best of luck!
I haven't really had a bad experience with Docker on Mac. but Is the idea you basically just build your service on top of specific.dev's provided services (postgres and redis) and those run bare-metal locally and then you can deploy to specific.dev's hosted solution?
>One thing I've been thinking about with agent infrastructure: the auth model gets complex fast when agents need to call external APIs on behalf of users. Per-key rate limiting and usage tracking at the edge (rather than in the container) has worked well for me. Curious how you’re handling the credential passing to containerized agents.
The way we handle secrets is at build-time we allow you to run scripts that can extract secrets and env vars host-side. The secrets get stored in a sqlite table (not baked into the coast image). When you start a coast, it injects those secrets -- you can decide how you the secrets should appear either as env vars, or if they should be written to the write layer. You're then able to trigger a re-injection of the secrets, so you can extract all the secrets again host-side and have them injected into all running coasts. This is useful because you don't have to rebuild and re-run just to update secrets.
Great question! You can configure multiple coasts, so you could have a coast running with isolated dbs/state and also a shared version (you can either share the volume amongst the running coasts or move your db to run host-side as a singleton). So its sort of left to the orchestration layer: you put rules in your md file about when to use each. There's trade-offs to each scenario. I've been using isolated dbs for integration tests, but then for UI things I end up going with shared services.
>Re: For example, if two agents are both making schema changes to a shared database service
Obviously things can still go wrong here in the shared scenario, but it's worked fine for us and I haven't hit anything so far. It's just like having developers introducing schema changes across feature branches.
>Also, the per-service strategy config (none/hot/restart/rebuild) seems like the right abstraction. Most of the overhead in switching worktrees comes from unnecessary full restarts of services that don't actually care about the code change.
Totally, at first switching worktrees for our 1m+ loc repo was like 2 minutes. Then we introduced the hot/none strategies and got it down to like 8s. This is by far one of the best features we have.
It works fine on mac (that's what we developed it on) and it's not nearly as much overhead as I was initially expecting. There's probably some added latency from virtual box but it hasn't been noticeable in our usage.
I think there's a quite a few things:
1) You need a control plane to manage the host-side ports. Docker alone cannot do that, so you're either going to write a docker-compose for your development environment where you hard code dynamic ports into a special docker-compose or you're going to end up writing your own custom control plane.
2) You can preserve your regular Docker setup without needing to alter it around dynamic ports and parallelized runtimes. I like this a lot because I want to know that my docker-compose is an approximation of production.
3) Docker basically leaves you with one type of strategy... docker compose up and docker compose down. With coasts you can decide on different strategies when you switch worktrees on a per service basis.
4) This is sort of back to point 2, but more often than not you want to do things like have some shared services or volumes across parallelized runtimes, Coasts makes that trivial (You can also have multiple coast configs so you can easily create a coast type that has isolated volumes). If you go the pure docker route, you are going to end up having multiple docker-composes for different scenarios that are easily abstracted by coasts.
5) The UI you get out of the box for keeping track of your assigned worktrees is super useful.
6) There's a lot of built in optimizations around switching worktrees in the inner bind mount that you'll have to manually code up yourself.
7) I think the ergonomics are just way better. I know that's kind of a vibesey answer but it was sort of the impetus for making Coasts in the first place.
8) There's a lot of stuff around secrets management that I think Coasts does particularly well but can get cumbersome if you're hand-rolling a docker solution.
Yeah, I think there's a ton of great remote solutions right now. I think worktrees make the local stuff tricky but hopefully Coasts can help you out.
Let me know how it goes!
1) Could you run an agent in the coast?
You could... sort of. We started out with this in mind. We wanted to get Claude Max plans to work so we built a way to inject OAuth secrets from the host into the containerized host... unfortunately because the Coast runtime doesn't match the host machine the OAuth token is created on, Anthropic rapidly invalidates the OAuth tokens. This would really only work for TUIs/CLIs and you'd almost certainly have to bring a usage key (at least for Anthropic). You would also need to figure out how to get a browser runtime into the containerized host if you wanted things like playwright to work for your agent.
There's so many good host-side solutions for sandboxing. Coasts is not a sandboxing tool and we don't try to be. We should play well with all host-side sandboxing solutions though.
2) Why DinD and why not mount namespaces with unshare / nsenter?
Yes, DinD is heavy. A core principle of our design was to run the user's docker-compose unmodified. We wanted the full docker api inside the running containerized host. Raw mount namespaces can't provide image caches, network namespaces, and build layers without running against the host daemon or reimplementing Docker itself.
In practice, I've seen about 200mb of overhead with each containerized host running Dind. We have a Podman runtime in the works, which may cut that down some. But the bulk of utilization comes from the services you're running and how you decide to optimize your containerized hosts and docker stack. We have a concept of "shared-services". For example if you don't need isolated postgres or redis, you can declare those services as shared in your Coastfile, and they'll run once on the host Docker daemon instead of being duplicated inside each containerized host, coasts will route to them.
Well the reason that works is because in grocery stores you have a concept of card present so the liability shifts to the issuing bank... so there are no chargebacks. Concepts like card present and card not present demand a centralized authority and really can't exist in a decentralized payment rail, unless you're going to somehow invent decentralized pos hardware for merchants. Once you enter the world of atoms, you have re-introduced centralized trust into your payment rail though.
> Convenient without poor people with no rewards cards subsidizing everyone else to cover Visa’s take.
I fully agree. This is a crappy part of ccs and the best remedy is to disallow rewards programs for credit products. This isn't a fault of the card networks its a fault of issuing banks (and the airlines). Every crypto company in 2021 was offering 8% APY, you think those guys would have been better about this than Amex?
> Maybe we don’t need an alternative when Visa handles everything, but it might be nice to not pay a 3% markup on everything.
I'm actually not bothered by a take from the banks and networks involved. They are underwriting risk and affording insurances to me and the merchant. I guess my main argument is that it's good to have centralized insurance in money transfer facilitation. 3% is high and a failure of Dodd Frank. The Durbin Amendment should have reigned in cc fees and not just focused on debit interchange.
> Alternatively, we could try to be more like India and Brazil, which each built instant bank to bank transfer setups you can use at the grocery store, without the risks that come with losing debit/credit cards.
I don't disagree. As you pointed out it really comes down to the crappy reward programs from the issuing banks that make merchants and poor people suffer.
I don't mind crypto as an idea. I don't have a horse in the crypto race either. What I mind is the notion that it is somehow a viable payment rail. I'm sorry, it's been 20 years and crypto's best use case for payments has been buying acid on the internet because it was the only payment option.
I think one of the most interesting business stories in the world is about the guy who invented the Visa network, Dee Hock. It truly is a story of decentralization at its finest. John Coogan did a great video on him a couple of years ago I highly recommend: https://www.youtube.com/watch?v=RNbi2cUZt1o.
At least with card networks, there are layers of liability if solvency issues occur. There’s merchant protections from the acquiring bank and if for some reason the acquiring bank fails there is the guarantee of the card network.
On the issuing side there are chargebacks. I hate chargebacks as much as the next startup bro but consumer protections are a necessary aspect of a functioning payment rail. There are reasons we don’t use ACH for everything.
I think hand waving the pesky settlement details is absurd. The settlement process is the payment rail.
If you do want those protections you end up back with a custodial wallet, which brings us back to a centralized model.
I’m not arguing crypto doesn’t have its place in the universe, I am arguing it’s a very bad payments product.
Writing that I feel back in 2021.
Yeah, so I had to lookup the leg after watching the movie. My interpretation was that it wasn't actually really surrealism. They juxtapose that scene with the lady reading from the newspaper about the attacking leg as if it was real. The reason I think this supports the "from the future journalist's perspective" interpretation is that those were legitimate articles ran, while there were serious cases not being reported on things like people going missing by the dictatorship. I think they included it to show the absurdity of what information was available and what information wasn't in the papers from that time. Also because of the lore of it all.
My take home at the end was that it was supposed to show the audience that the story was recreated from the parts of the story that could be pieced together by the future journalists. Basically it felt meandering because it was meandering to the journalists trying to figure out what happened. The ending with the son was the journalist trying to tie everything together for herself but he just didn’t have the information. Still dissatisfying.
I also find that it's way more effective to live in the comment sections. Rarely does the "Hey, look at me, I'm selling a piece of software" post genuinely do well. It's always so tempting to do that too but It's way better to find someone asking specifically for a thing you're solving and respond to the individuals.
We specifically don't solve the env vars per directory problem, so this is really cool to see.
It's crazy the see the amount of hackery we're all having to figure out with worktrees, way cool to see all these solutions popping up.