No, I literally am paying for the thought process, per token. "Pay only for the result" is not how these things are billed.

> Text a human wrote or edited should be considered close to sacred: an agent should be hesitant and have a very good reason to touch it.

Not sure I agree (particularly with code, not prose). If code is risky to change for reasons that aren't obvious, it should be commented as such. It doesn't matter how the bytes were generated.

> Another use case: the README.md, originally generated, where you rewrite the opening paragraphs. The agent should feel free to redo or append parts further downwards but should really think twice changing anything in the opener.

This, I understand.

Moreover, from tfa:

> This Dell also beats out both M4 and M3 Mac Studios, only failing to the M4 Mac Mini at 7.57 Gflops/W.

If you've ever been put off by the difficulty of the language, it's worth checking it out again with AI assistance.

To be clear, I do not support Flock cameras.

[0]: https://www.nbcbayarea.com/news/local/san-francisco/san-fran...

You know what software doesn't fill me with dread to update? FOSS.

Proprietary software isn't built for users anymore. But (some) FOSS still is.

Comments URL: https://news.ycombinator.com/item?id=49016576

Points: 4

# Comments: 1

why would anyone sign such a contract?

It's running, privately, in my homelab.

I think we are entering what I call the "have it your way" era. If an open source project doesn't do exactly what you want it to do, fork it, or create a new version. It's too easy.

This makes me a bit concerned about the future of open source. Upstreaming used to be worth it, since maintaining a fork is effort too. But now the balance has shifted significantly. Especially with many projects becoming a lot stricter about contributing, and some becoming outright hostile to AI. I can't blame them. But I think the effect will be that improvements are less likely to make it back to the community as AI adoption increases.

But it has proven quite the challenge to support old Linux distros. We have tried using nix to pin deps, but this easily leads to new issues: hardcoded RPATHs leaking into binaries, glibc compatibility issues, etc.

If we instead fork the build environment and use an old Ubuntu for building our Linux app, then my life gets harder, because now I have two targets for a whole lot of internal tooling that my team maintains, and that tooling needs to be deployed to both build environments. Again, its the same shit: glibc mismatches, missing/different shared libraries, etc. Just causing problems in a different place.

There is certainly some element of skill issue at play. But I wouldn't call it easy.