zimbatm
CLIs live in the same namespace as the agent, so any secrets the CLI needs access to, the agent can also exfiltrate. And access control is lightly gated by the agent's tool call policy.
For an enterprise-level deployment, it becomes quickly desirable to have a centralized MCP backbone, on which each MCP is attached to. A place you can attach policies to, log activity, and reason about access control.
Otherwise it's just FUD.
We need this also for normal usage like development environments. Or when invoking a command on a remote server.
Are you going to add support for services that don't support OIDC or this going to be a known limitation?
nix run github:numtide/llm-agents.nix#mistral-vibe
See https://gerrit-review.googlesource.com/Documentation/note-db...
The content of the AGENTS.md is the same as what humans are looking for when contributing to a project.
`nixos-rebuild build-image --image-variant vmware`
See https://nixos.org/manual/nixos/stable/#sec-image-nixos-rebui...
My assumption was that a tool like this will make it easier to keep the README.md in sync while the project evolves. Think of a `--help` section. That assumption holds true to me.
You can see it in action for example here: https://github.com/numtide/treefmt-nix?tab=readme-ov-file#su...
The best part is that it makes it easy to keep the README.md in sync when the project evolves. Just add it to the CI
There are tools like Jupyter notebooks that have all the functionalities, but their file format isn't very readable or diffable using standard terminal tools.
A while back I wrote https://github.com/zimbatm/mdsh to explore the space. Voiden.md looks like a fancier version of that.
The main reason even Microsoft gave up and rebased their browser on top of Chrome is because of the breakneck speed at which Google introduces new standards and features to the ecosystem. Having them be forced to slow down might be a good thing for browser diversity and the future of the Internet.
I'm not going to invoke the slippery slope argument, but what distinguishes Go from the pack is how explicit it is. It can make it more tedious to write, but also much easier to follow as a reader.
Not all use-cases are faster with virtiofs.
Transparent decryption sounds nice. Until you commit decrypted secrets by mistake.
Because the encryption/decryption is transparent, you won't notice if the .gitattributes pattern-matching is wrong until it's too late.
I did this myself and saw it happen in the wild as well.
Sometimes, the worker can return a signed URL and have the client directly upload to R2.
Are there other details you are willing/allowed to share, like the number of objects in the store and the number of servers you are balancing them on?
So now you're asking your users not only to bless the EFI loader, but also to resize their ESP, and most likely system partition.
1. Introduce a X-PEGI HTTP header that sites can use to change the content. This would also be useful for other contexts such as cybercafes and whatnot.
2. Mandate that porn website abide by these headers.
3. Have responsible parents, lock their children's computers and add the appropriate header.
The adults then have access to the adult internet with no extra restrictions.
This seems like a pure passion project: to return to the pleasure of building something just for the sake of it. Design and explore. Hack.
Not every endeavour has to become a product. As soon as you get users, you get obligations, and this tends to destroy these feelings.
A better way would allow you to push your changes as stacks of commits. No branches. Just push, and have a CI that automatically builds, tests, merges and deploys your commits. And everything that didn't pass gets handed back to you. Instead of change reviews, do pairing and code reading sessions.