A well-behaved application should not only use XDG on Linux, but it should use platform-native conventions on macOS as well: "~/Library/Application Support", etc.
Yes, and the Windows app-data equivalent. The point is that you have to be a good citizen of the platform on which you're running. curl | bash is kind of a selfish model.
This kind of stuff often breaks for applications packaged with Nix, so it's often removed from Nix packages for compatibility reasons. Both behaviors you mention are helpfully patched out of the Claude Code package I use: https://github.com/numtide/llm-agents.nix/blob/dc285bfd94ec7...
As a result, I never knew that Claude Code does a nasty thing like this, either. :-\
Fwiw, packages in that repo get version bumped each day, so if that's a fast enough pace for you it may be a good alternative.
There aren't any documented settings to disable this, but there is a feature flag it currently sits behind. You can flip it in your ~/.codex/config.toml[1]:
[features]
daemon_auto_start = false
There are also some files that it writes to in ~/.codex at startup: pid files, lock files, things like that. You can delete them and replace them with symlinks to /dev/null, then mark those unwritable with `chattr +i` or similar. Presumably then the background daemon will crash on startup, if the feature flag ever goes away.
What makes ACP deficient for headless uses of LLM agents? Maybe fixing that or standardizing on another protocol designed for pluggable LLM agents (I guess ACP is more oriented towards pair programming in an IDE, at least originally) is a better idea imo.
Yep, the real issue is that it was something they didn’t have before, and then with Codex 0.157.0 enabled, they installed this persistent nonsense [1] that survives after the last instance of Codex has exited on your machine, which is just gross.
For whatever reason, the daemon has been refusing to start and Codex has been grumbling to me. I was wondering where the daemon had come from, and thought maybe I missed something previously and that it had just broken.
One thing I hope IBM understands here is that healthy F/OSS projects aren't really the kind of thing you can buy and proprietarize even by "forking"/re-licensing your own code. Ages ago, Oracle learned this when they bought Sun, particularly with the birth of The Document Foundation and LibreOffice. More recently, Hashicorp is facing the same phenomenon with the departure of the chief maintainer of Terraform to work on OpenTofu at Spacelift.
Many F/OSS maintainers care pretty deeply about things like software freedom, taking good care of our digital commons, and leaving their mark on the world in a public way. I imagine that's especially true at Red Hat. You can buy the company, you can change the relationship to the community of "outside" contributors, and you can even release new versions of the software under a proprietary license. You can create upheaval for a lot of people, including the users. But you will often not only fail to walk away with key maintainers on your team, but watch them go on to form your competition on a new fork.
I don't personally know anyone who works at Red Hat, but even from the interactions I've seen recently in issue trackers and PRs to projects maintained in part by Red Hat engineers, I'm inclined to have a bit of faith. The upstream-first culture there still seems pretty strong and pretty quality-oriented to me. I don't think you can reliably keep engineers like that and turn them into drones who don't care about the craft and their impact on users and developers.
Does "external" contributors effectively mean drive-by contributors? I assume there's still more than a single developer, and it's somehow possible to be admitted as a member of the project if you have some existing public reputation.
I chose to listen to the blog post instead of just reading it. I don't know how much if it is just the idea of AI-generated music for me, but the listening experience was extremely repulsive.
(I mean that seriously, actually— I don't think people who have used both but prefer Vim would generally list "more powerful" among their reasons for preferring Vim. It's usually more about not liking Lisp, some kind of "minimalism", or a different sensibility about composability.)
Well, Vim is not some concrete implementation, it's not like "Photoshop", where it means a specific product line, it's an idea. "The power of Vim" is its grammar, the grammar is design, and designs port - that's why Helix, Kakoune, Evil-mode, Meow, etc. exist. I agree that the "command structure" you're referring to may feel better than modifier-chord scheme of vanilla Emacs, where commands are a flat namespace - a mixed bag of bindings with no algebra connecting them.
However, the years of muscle-memory might be deceiving. Vim's objects are text-shaped - the design has no idea of what a function or an expression is. Vim's grammar is excellent but its nouns are approximations. The modern answer perhaps to keep the grammar and upgrade the nouns, which is what tree-sitter text objects attempt of doing.
Anyway, my main point is not about the grammar, but about the grand idea. The idea of Vim is a beautiful, pragmatic model and it can be perfectly used outside of Neovim. If you truly want to take it to another level, maybe consider combining it with the power of Emacs.
Innovation and insight rarely happen within a single substrate - you typically need to explore intersections of divergent disciplines. Emacs itself is rooted in another grand idea, arguably one of the most important ideas in all the history of computer science - a practical notation for lambda calculus widely known as "Lisp". Once you understand the immense, pragmatic value of that idea, it eliminates any skepticism you might have held against it.
If you think Emacsians don't get vim, well, you're misinformed. There are thousands of vimmers who choose to be viming in Emacs. Because Emacs vims better. As a die-hard vimmer I can attest.
You would think that no one would be stupid enough to use Fable or Sol for small one-off tasks like filtering tweets, but AI has opened up a lot of avenues for stupid people to ship code. It's only going to get worse.
yeah man it's me who's stupid and not you when i use an example of the author who claims that you can use pro subscription on all of the mundane tasks w/o going over the budget. sure. my point is that you can only use it with cheaper models. also some tweets are fairly dense in their compression/context, so yeah sometimes it's necessary.
If you factor in cost then it may well be, but it's definitely the case that the high-end models can get you significantly better results than the cheaper models even for tasks that feel like they should be straightforward.
https://github.com/numtide/llm-agents.nix/
reply