3 ms·

Yeah I think this is changing, fast. 100% agree on "clone X and tell me how it works". I'd also add: "clone X and see how it does Y; use that as design referen

Yeah I think this is changing, fast. 100% agree on "clone X and tell me how it works". I'd also add: "clone X and see how it does Y; use that as design reference for building feature Z" if licenses permit. On modifying software... I forked codex in ~Dec and had my own lightweight "plan mode" and a few other things. It was fun and satisfying, but it ended up being a bit of a pain to keep updated. The models were less good then, and maybe I should have learned some rust first. But it was close. For a less fast-moving codebase it'd have worked, and that was 8mo ago. On the other hand as someone building in devtools for the first time, I struggle with how to think about this. We're building a cloud agent + sandbox platform, https://boxes.dev https://boxes.dev - same problem space as the author's product exe.dev. We could open source our client or the whole stack (we've been thinking about it), but we're adding stuff so quickly that anyone customizing would have a hard time with updates. There's also a lot on the hosted side that users couldn't modify unless they self-host. But I like this vision of a world where software is some fluid thing, and everyone is writing personal mods and building off of others' - basically OSS with forks but where every user (or their agent at least) is engaged with the code.

awesome_dude 2mo ago
> On modifying software [..] It was fun and satisfying, but it ended up being a bit of a pain to keep updated. I don't mean this as a criticism in any way - but the need to keep your changes current is a strong motivation for getting those changes incorporated upstream.
- dolmen 2mo ago
  > but the need to keep your changes current is a strong motivation for getting those changes incorporated upstream. But the cost of contributing changes made by AI is higher: * high chance of the being just rejected because code made by AI, or PR made by AI * so contributing would require carefully preparing a human-made patch (but that becomes much more work than telling an agent to just upgrade my fork) * there is still a high chance for the patch to be rejected or just ignored for months/years, like before Also, there are much more vibe coded projects which are open source, but the author has no interest in maintaining, so issues/PRs will just be ignored.
- dregitsky 2mo ago
  Yep fair point. In my case I don't think codex team was really considering outside contributor PRs except bugfixes, plus my idea of "plan mode" was prob not what they wanted to ship in their product. But maybe I should have tried!
aleqs 2mo ago
How are you handling the actual provisioning of the agent boxes/VMs? Are you using a specific provider/cloud, or multi-provider? Are there any providers/clouds you've found are better/worse for your use cases? Asking because I am working on an open/standard protocol/layer for provisioning cloud resources across different providers. One of the ideas is to provide a marketplace of providers/resources via one unified/standard API, which I would allow automatic selection and provisioning of VMs (and other resources) based on price/value/feature/reputation requirements/priorities.
- kami23 2mo ago
  Coder uses terraform providers to do the provisioning. I think that's the correct layer of abstraction, all major providers will be there and can be customized with the modifications needed via various other terraform features. I've written three different solutions for platforms that solve this standard protocol layer. What has worked for us was deciding to standardize on the Kubernetes API for our services back in 2017, and then from then on, all our providers have provided either a k8s API to interact with resources, or provide a Cluster API for provisioning. For example we have two datacenter VM providers that implement the k8s API and we've been able to swap the providers with no user refactoring, it's a good solution in hindsight with how many people have k8s in their stack. For the second big feature you're thinking of, we never really go a good solution to this problem, a lot of our workloads are long lived and not necessarily spot instance-able, but it's a very fun routing problem. Most of our need to be in multiple clouds is that we want to heavily separate our customer facing services, and keeping it away from internal workloads that support those customer APIs. Is this public work? I'd love to take a look. This is my bread and butter.
  - aleqs 2mo ago
    Yeah using terraform providers is a great idea and something I have considered and aim to support. The thing I'm building also aims to handle things like payments and identity, not directly but with a plug/play facilitator model - so different providers/users can support/use different payment methods, crypto, decentralized identity, etc. That part kind of sits outside the resource provisioning part, and the resource provisioning part could in theory be terraform providers (after identity/payments is established). Resource discovery and search including - specs, pricing, region, capabilities, etc. I envision this protocol being used to build both centralized and decentralized compute/cloud resource marketplaces. In the decentralized view - regular users sharing/renting their hardware/resources with each other... lots of security/abuse risks/questions there. I will be publicly releasing everything ~soon (I hope), it's in a pretty early stage at this point, many open questions.
deleted 2mo ago
[deleted]
SOLAR_FIELDS 2mo ago
As an end user, I don't mind if you're building a product with rapidly changing API's out in the open. I'll still use the product if it's useful and deal with the churn. What I DO care about is not having half of that project rug pulled 12 months down the line when your Series B folks decide that this particular money knob needs to be turned up. So if you want to not piss off your users, that's the way to do it. Build a model where you can actually sustain the product, and no, giving it away on seed and series A round money then rug pulling that gift is not the way to achieve that.
nextaccountic 2mo ago
> if licenses permit. As if licenses mattered in the LLM era Case in point https://news.ycombinator.com/item?id=48466812 https://news.ycombinator.com/item?id=48466812 > In looking at the code that the LLMs have produced for the project, especially given the pretty massive and widespread architectural changes needed to make the implementation libified and memory safe, we decided that the codebase is not a derivative work that would require carrying forward the GPL license and have decided to release the code under the MIT instead. LLM are copyright laundering machines Not only they launder copyright from Internet at large, they can also launder from specific targets
- nine_k 2mo ago
  > As if licenses mattered They still do, if you want your changes be made public, or even upstreamed. No sane license that gives access to the source code forbids modification for internal use; one reason is that it would be really hard to enforce.
  - nextaccountic 2mo ago
    Grit isn't made for internal use though, and it's still changing the license
- bonzini 2mo ago
  I am doing something similar to that C-to-Rust rewrite. Except: 1) I'm clearly saying that it's only for my own learning experience and to find ways to improve the original program 2) I am leaving the original license in place and explicitly treating the output as a derivative. And yet I am worried that my actions are perceived as hostile. Some people just don't care.

awesome_dude 2mo ago

> On modifying software [..] It was fun and satisfying, but it ended up being a bit of a pain to keep updated. I don't mean this as a criticism in any way - but the need to keep your changes current is a strong motivation for getting those changes incorporated upstream.

dolmen 2mo ago
> but the need to keep your changes current is a strong motivation for getting those changes incorporated upstream. But the cost of contributing changes made by AI is higher: * high chance of the being just rejected because code made by AI, or PR made by AI * so contributing would require carefully preparing a human-made patch (but that becomes much more work than telling an agent to just upgrade my fork) * there is still a high chance for the patch to be rejected or just ignored for months/years, like before Also, there are much more vibe coded projects which are open source, but the author has no interest in maintaining, so issues/PRs will just be ignored.
dregitsky 2mo ago
Yep fair point. In my case I don't think codex team was really considering outside contributor PRs except bugfixes, plus my idea of "plan mode" was prob not what they wanted to ship in their product. But maybe I should have tried!

aleqs 2mo ago

How are you handling the actual provisioning of the agent boxes/VMs? Are you using a specific provider/cloud, or multi-provider? Are there any providers/clouds you've found are better/worse for your use cases? Asking because I am working on an open/standard protocol/layer for provisioning cloud resources across different providers. One of the ideas is to provide a marketplace of providers/resources via one unified/standard API, which I would allow automatic selection and provisioning of VMs (and other resources) based on price/value/feature/reputation requirements/priorities.

kami23 2mo ago
Coder uses terraform providers to do the provisioning. I think that's the correct layer of abstraction, all major providers will be there and can be customized with the modifications needed via various other terraform features. I've written three different solutions for platforms that solve this standard protocol layer. What has worked for us was deciding to standardize on the Kubernetes API for our services back in 2017, and then from then on, all our providers have provided either a k8s API to interact with resources, or provide a Cluster API for provisioning. For example we have two datacenter VM providers that implement the k8s API and we've been able to swap the providers with no user refactoring, it's a good solution in hindsight with how many people have k8s in their stack. For the second big feature you're thinking of, we never really go a good solution to this problem, a lot of our workloads are long lived and not necessarily spot instance-able, but it's a very fun routing problem. Most of our need to be in multiple clouds is that we want to heavily separate our customer facing services, and keeping it away from internal workloads that support those customer APIs. Is this public work? I'd love to take a look. This is my bread and butter.
- aleqs 2mo ago
  Yeah using terraform providers is a great idea and something I have considered and aim to support. The thing I'm building also aims to handle things like payments and identity, not directly but with a plug/play facilitator model - so different providers/users can support/use different payment methods, crypto, decentralized identity, etc. That part kind of sits outside the resource provisioning part, and the resource provisioning part could in theory be terraform providers (after identity/payments is established). Resource discovery and search including - specs, pricing, region, capabilities, etc. I envision this protocol being used to build both centralized and decentralized compute/cloud resource marketplaces. In the decentralized view - regular users sharing/renting their hardware/resources with each other... lots of security/abuse risks/questions there. I will be publicly releasing everything ~soon (I hope), it's in a pretty early stage at this point, many open questions.

deleted 2mo ago

[deleted]

SOLAR_FIELDS 2mo ago

As an end user, I don't mind if you're building a product with rapidly changing API's out in the open. I'll still use the product if it's useful and deal with the churn. What I DO care about is not having half of that project rug pulled 12 months down the line when your Series B folks decide that this particular money knob needs to be turned up. So if you want to not piss off your users, that's the way to do it. Build a model where you can actually sustain the product, and no, giving it away on seed and series A round money then rug pulling that gift is not the way to achieve that.

nextaccountic 2mo ago

> if licenses permit. As if licenses mattered in the LLM era Case in point https://news.ycombinator.com/item?id=48466812 https://news.ycombinator.com/item?id=48466812 > In looking at the code that the LLMs have produced for the project, especially given the pretty massive and widespread architectural changes needed to make the implementation libified and memory safe, we decided that the codebase is not a derivative work that would require carrying forward the GPL license and have decided to release the code under the MIT instead. LLM are copyright laundering machines Not only they launder copyright from Internet at large, they can also launder from specific targets

nine_k 2mo ago
> As if licenses mattered They still do, if you want your changes be made public, or even upstreamed. No sane license that gives access to the source code forbids modification for internal use; one reason is that it would be really hard to enforce.
- nextaccountic 2mo ago
  Grit isn't made for internal use though, and it's still changing the license
bonzini 2mo ago
I am doing something similar to that C-to-Rust rewrite. Except: 1) I'm clearly saying that it's only for my own learning experience and to find ways to improve the original program 2) I am leaving the original license in place and explicitly treating the output as a derivative. And yet I am worried that my actions are perceived as hostile. Some people just don't care.