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

61–70 of 262 posts

Re: Devtools must be open source

#61

Post by Brainspackle »

the_explainer2 wrote: post #46
Brainspackle wrote: post #44

Earlier quoted context omitted.

exe.dev has quickly become my platform of choice for hosting, testing, playing and tinkering. I haven't had this much fun playing with a providers offerings since VMs were a new thing. You have no idea what you're talking about here and should do a little research on them first. What you are saying they are, is not that.

https://exe.dev/docs/shelley/llm-gateway "The exe.dev LLM gateway provider source within an LLM integration remains supported. It provides exe.dev-managed access to Anthropic, OpenAI, and Fireworks models. Your subscription includes a monthly token allocation, and you can purchase additional tokens at https://exe.dev/user/shelley ." The access to closed platforms is managed according to the docs.

You don't need to use the LLM integration at all if you choose not to and even without it, it's a lovely service.

I've used the LLM only a few times to make a few sysadmin tasks easier that I could have easily done myself.

Re: Devtools must be open source

#62

Post by swiftcoder »

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…

> Most people can't justify the time commitment needed to read and then modify the code for tools they use very often.

Hell, even when I can justify the time commitment for that, I can't justify the ongoing maintenance burden of fixing up my patches to work on the latest version every release or major security fix...

Re: Devtools must be open source

#63

Post by skybrian »

lalitmaganti wrote: post #50

As a maintainer of a devtool which has strived to make itself easily forkable and modifiable, I can see the allure of this line of thinking but I think it's sadly too idealistic. Engineers using devtools are not so different to an average user in that they just want things to work. Maintaining a devtool is real work; e.g. suppose upstream adds some feature you want but it clashes with something you did downstream. No…

The idea is that upgrading a devtool is like upgrading a vendored library. It's not something you do automatically or while you're in the middle of doing something else. Usually the AI can fix merge conflicts. If upstream changes are too extensive, you can have the AI rewrite the change entirely.

I think will work better for nice-to-have features that are ultimately disposable if they become too hard to maintain.

Re: Devtools must be open source

#65

Post by a3mrouter1 »

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…

[flagged]

Re: Devtools must be open source

#66

Post by [deleted] »

simonw wrote: post #43
throwatdem12311 wrote: post #36

Earlier quoted context omitted.

Then you’re maintaining a stack of patches on top of the upstream until the end of time because the maintainers of the projects don’t want AI slop contributions, but now you depend on these changes for your own use so now you’ve created more work for yourself keeping your own fork up to date. I used AI to help me make a change to a library I use that ended up being a single line of code. The pull request was refused…

> Then you’re maintaining a stack of patches on top of the upstream until the end of time The linked article has an ambitious solution for that, in the form of this prompt to a coding agent harness: 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.

[deleted]

Re: Devtools must be open source

#67

Post by 8n4vidtmkvmk »

hombre_fatal wrote: post #47
throwatdem12311 wrote: post #36

Earlier quoted context omitted.

Then you’re maintaining a stack of patches on top of the upstream until the end of time because the maintainers of the projects don’t want AI slop contributions, but now you depend on these changes for your own use so now you’ve created more work for yourself keeping your own fork up to date. I used AI to help me make a change to a library I use that ended up being a single line of code. The pull request was refused…

Maintaining a fork seems trivial for an LLM. Replaying each upstream commit against your fork is exactly what even dumb models can do without issue. But at the same time LLMs also let you question why you’re using a dependency if it’s causing certain issues for you. e.g. I got tired of waiting for libghostty to publish a new stable release since the one in March which would have a memory leak fix I reported, so I spe…

I too built a terminal emulator and I like it, but I wouldn't say it's easy to maintain even with LLMs. The # of edge cases is insane.

Re: Devtools must be open source

#68

Post by throwatdem12311 »

throwaway27448 wrote: post #40
throwatdem12311 wrote: post #36

Earlier quoted context omitted.

Then you’re maintaining a stack of patches on top of the upstream until the end of time because the maintainers of the projects don’t want AI slop contributions, but now you depend on these changes for your own use so now you’ve created more work for yourself keeping your own fork up to date. I used AI to help me make a change to a library I use that ended up being a single line of code. The pull request was refused…

> even though it was a single code change that was syntax only with no change in behavior just to make it compatible with an older version of the language they claimed to support It seems like a great stretch to call this "slop".

I agree but it’s their project and their rules. To them I’m just another guy tossing slop over the fence they don’t have time to review in the hig stack of all the other slop.

Re: Devtools must be open source

#69

Post by Terr_ »

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…

> the freedom is more about being able to lean on other people to do that

Alternately: The collective capability is what makes important lasting changes, but individual capability is still a required building-block to get there.

Much like freedom of speech, come to think of it.

Re: Devtools must be open source

#70

Post by traceroute66 »

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…

> Most people can't justify the time commitment needed to read and then modify the code for tools they use very often.

A lot of modern open source software is often written in dependency heavy languages.

So to do a "proper" examination, by definition you need to consider the dependencies as well as the core code itself. We all know how supply-chain attacks are on the rise.

Post reply on HN