Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Devtools must be open source

blog.exe.dev

Post reply on HN
Print view View original

171–180 of 262 posts

Re: Devtools must be open source

#171

Post by aleqs »

kami23 wrote: post #155
aleqs wrote: post #129

Earlier quoted context omitted.

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/st…

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…

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.

Re: Devtools must be open source

#172

Post by pjmlp »

wredcoll wrote: post #169
pjmlp wrote: post #111

Earlier quoted context omitted.

HackerNews, the site when someone posts about their business for developer tooling, there is always a bunch of folks posting links about half implemented alternatives, because who wants to pay for tooling like any other professionals?

Is there some magical utopian profession where people want to pay for tooling? Like, I'm sure there are people/groups who spend more on tools, like say, all the plumbers and carpenters buying $600 dewalt drills or whatever, but I'm having trouble with the idea that they want to do that. If programmers, on average, don't pay very much for tooling, the magic of capitalism tells me that's because the tools aren't worth…

You don't need $600 dewalt drills to open holes for most carpenter's.

Ah, but we used to pay, and many of us still do, because as programmers, some of us also like to earn salaries, we don't get to buy groceries with pull requests.

Re: Devtools must be open source

#174

Post by dregitsky »

aleqs wrote: post #129
dregitsky wrote: post #59

Earlier quoted context omitted.

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…

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/st…

For boxes.dev we use E2B - they had everything we needed at the time. I'd love a standardized API / marketplace, but more just to try out new providers with differentiated features or pricing - we probably wouldn't be switching often / using multiple (unless customers asked us for more options). There are so many sandbox providers popping up!

Our use case is pretty specific though - one persistent machine that you set up your full developer environment on, then ability to very quickly spin off full copies of that machine (filesystem + memory) as separate VMs to run agents on. Firecracker VMs + support for "forking" the box were our key requirements. Another provider that could do this was Modal, but they use gVisor and not Firecracker, which means it's harder for users to run docker inside the box.

Re: Devtools must be open source

#175

Post by dregitsky »

awesome_dude wrote: post #110
dregitsky wrote: post #59

Earlier quoted context omitted.

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…

> 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.

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!

Re: Devtools must be open source

#176

Post by nightshift1 »

katbyte wrote: post #163
mbreese wrote: post #109

Earlier quoted context omitted.

This is actually not a bad idea for funding open source software. It used to be that you’d have an author who coded a project and then could fix the occasional bug or two quickly. Now, we have larger projects where it is rare for one people to have a complete understanding, and the main value is a person to reviewing patches and bugs to make sure the changes align with the larger goals/path for the project. There is…

Opportunity for gh “Here is my pr I attach x$ payable when it is merged” and allow me to add $ to other prs. I have been waiting year + for multiple feature in some projects that have open prs and for one I would easily bid 100-200$

[dead]

Re: Devtools must be open source

#177

Post by bonoboTP »

zephen wrote: post #166
bonoboTP wrote: post #82

Earlier quoted context omitted.

The two are correlated which does encourage that mistaken view. Github culture generally blends these two, having an open issue tracker, pull requests etc. as well as the code right there, often with a free license. But you can very much allow bug reports and feature requests in public while developing proprietary software and you can also very much work on a project alone or with a small group without being open to…

Plenty of proprietary packages had robust communities well before anything like github existed. In fact, github is arguably a poor substitute for a community. Look at how communities such as the ones around the linux kernel or cPython communicate. It sure as shit isn't through issues or pull requests. Or rather, perhaps, the limited technical communication that an issue tracker is good for is not a valid large commun…

Yes. I've actually added some features to Blender like this, related to some highly specific use case. Just clone the source point an agent at it, say what you'd want (you have to be able to formulate this in a halfway coherent way), and it succeeded. Now, I haven't thought much about what it would mean to maintain this, but I think if I need this ever again, I can point an AI to it again and say "do the equivalent change now to the latest version". For occasional use this is fine.

Re: Devtools must be open source

#178

Post by apitman »

theamk wrote: post #15

> Set up a nightly cron job that executes the prompt: fetch upstream changes to the and rebase all local changes on top of upstream. Check that the software works as intended and replace the current version. This sounds like hell. You have unreliable actor redoing the software every night, and every day there is a chance you wake up and find your workflow broken. And no, "Check that the software works as intended" is…

If your coding agent workflow isn't sandboxed, backed up, and rollback-able, it's fundamentally broken. And yes I realize most of us aren't working this way today. But I think we'll have the tooling pretty soon. There's currently a cambrian explosion of solutions in this space.

Re: Devtools must be open source

#179

Post by 9dev »

theamk wrote: post #15

> Set up a nightly cron job that executes the prompt: fetch upstream changes to the and rebase all local changes on top of upstream. Check that the software works as intended and replace the current version. This sounds like hell. You have unreliable actor redoing the software every night, and every day there is a chance you wake up and find your workflow broken. And no, "Check that the software works as intended" is…

I don't know; I've been rebasing huge branches in really mean divergent states with Claude Code, and it handled it flawlessly pretty much every single time. So I don't think the actor is as unreliable as you think.

Re: Devtools must be open source

#180

Post by nextaccountic »

dregitsky wrote: post #59
simonw wrote: post #3

One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. I think LLMs have changed…

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…

> if licenses permit.

As if licenses mattered in the LLM era

Case in point

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

Post reply on HN