221–230 of 262 posts
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…
That's the memed magical thinking of "make no mistakes"
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…
> 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 GP…
And yet I am worried that my actions are perceived as hostile. Some people just don't care.
Earlier quoted context omitted.
I have sent countless small bug fixes even before, to tools that I use that I could dig into when something was off... No big heavy lifting, but plenty of "tinker on your tools" stuff. And I don't think what I did was that special, so maybe the experiences are different? The current LLM-driven stuff seems to break down the expectations, and now there are a lot of places which just ignore anything I send in (the same…
The solution for this is to pay open source maintainers for their attention. If I want them to review and merge my bugfix I should attach $1000 to the PR.
If that gets fixed, the project gets the money.
I liked your article on its merits but this: > Both the upfront fixed costs and the ongoing costs of personalizing software have disappeared. Is just wishful thinking, at best. We can say your own quirky little personalised software that works on your computer might have become cheaper. Production grade software that people pay for is a different beast. That’s why people pay for software: support and ongoing maintena…
I agree that devtools should be open source, but... I very much disagree with the premise that no tools should have config files, options, or plugin systems, and instead when you want to change something like your text editor's font size, you should have an LLM download the code, change the hard-coded value, and rebuild it. That's just so inefficient and wasteful. Assuming a world in which LLMs do most of the coding…
I completely agree - we've seen that tools with plugins are really scalable and then allow the better plugins to be folded back into the main tool where they become popular. I've taken that approach with my own dev tools that I've created.
I agree that devtools should be open source, but... I very much disagree with the premise that no tools should have config files, options, or plugin systems, and instead when you want to change something like your text editor's font size, you should have an LLM download the code, change the hard-coded value, and rebuild it. That's just so inefficient and wasteful. Assuming a world in which LLMs do most of the coding…
Earlier quoted context omitted.
> The new personalization talking point appears to be coordinated. It is all over the Internet since last week. I agree with you. They are manipulating public opinion, fooling users.
Hi, author here. FWIW, the only people I coordinated with are my colleagues at exe.dev. Philip wrote a blog post a week ago on the topic too: https://blog.exe.dev/customizing-shelley . In retrospect, I should have sent drafts of this to other people I know thinking about new dev tooling to get their feedback! A bit more private discussion could have let me polish this more. We are all busy discovering the shape of ne…
It turned out EF had a stage named "view generation" which verified that data would round-trip, meaning if it goes into the DB and comes back, would stay the same. Run time was exponential on the number of tables and complexity of models.
People used tricks to work around it, which was basically caching the "generated view" in a file, which could speed up the production startup, not as easy in DEV environment, our programmers still needed to wait 2 minutes after each compile.
I started looking into it, and it turned out that Microsoft had open sourced EF a short time ago (long after we had started the project).
While profiling, view generation took much longer, 450s, as it was a CPU-heavy process. There was a function excluded from release builds by a `[Conditional('DEBUG')]` attribute, and when I removed the call to it, the time went down to 64 seconds, 63 of which was in a very simple function. A LINQ statement in there could be re-written to make it 120ms.
I ended up contributing it to EF core, being acknowledged in their blog post, and we ended up using our own release build of EF libraries until the fix made it to the public release.
Had they not open sourced EF, it could turn into an existential threat to the project.