281–290 of 330 posts
Earlier quoted context omitted.
I'm more worried about my `~/.aws` and `~/.ssh` folders. People who use IDE-based AI tooling with IDEs that support dev-containers have no excuse for not leveraging dev containers, both for preventing agents losing your data and defending against secrets-harvesting supply-chain attacks
Using containers as a security boundary is inexcusable.
Earlier quoted context omitted.
Well, the agent should help you by saying "hey, I cannot do this task, but I can bypass the problem by doing this, but obviously it is not something you intended me to do or even something you were aware of, so I will not do it unless you tell me explicitly it's ok". It's win-win: the agent is helping and it is educating you about things you obviously did not realise.
That works great if it's one agent, absolutely doesn't if you want to tackle something complex that warrants using ..say.. ten agents. I can imagine a future where this technology empowers you to do things with a thousand agents.
I'm not sure what is your point: are you saying that in a multi-agent workflow, you will have one agent per letter read on the file? I would assume that each agent as a specific unitary "task", instead of having each agent doing one cpu instruction each without any knowledge of the bigger picture. The point of multiagent is to parallelize tasks that can be parallelize, not removing the context, in which case you are wasting money using an agent.
Earlier quoted context omitted.
I too have learnt to like systemd. But what is the relevance here? In what way is it a replacement for docker?
> In what way is it a replacement for docker? Look at the man pages for `machinectl` (then `systemd-nspawn`, `systemd-vmspawn`, and if you want `systemd-portabled`). This is a replacement for docker. These are container tools offered by systemd.
Earlier quoted context omitted.
Is it really that much worse than using a package manager that drops a binary that you're not going to inspect anyways?
Yes, it is worse because using your package manager trusts your distribution (and the packages packager), doing curl bash trusts a random website. While in this case docker is not a random website, it's best to use the package manager when available
Is installing docker from docker own APT repo actually safer than curling a binary from docker's website?
Earlier quoted context omitted.
This feels like using Docker is just inherently unsafe.
This feels like using sudo is just inherently unsafe.
Instead of having "root" and "user", both of these provide sets of permissions that can be granted to apps.
In this case, SELinux would've stopped this. Codex could've still relabelled the files when mounting but this can be blocked for sensitive directories like /etc.
Earlier quoted context omitted.
Once I noticed that models will treat lack of superuser access as an obstacle I moved all of the agent crap to its own machine. Watching some mid-tier offering chain together tools like its a gorilla escaping the zoo and I'm just not going to deal with that situation.
It's why all of my agent run in a vm. I refuse to have it run on my own machine. Claude code once managed to render the vm unbootable, I was back in action 5 minutes later after regenerating the vm
I recently took the risk there by having it run xattr commands to fix some MacOS bug with Tahoe that broke auto update for what seems like all software.
Earlier quoted context omitted.
That’s what rootless docker is for
rootless docker's networking (slirp4netns) is still terribly buggy and in edge cases often locks up using 100% CPU until you discover that your laptop is a lapwarmer and kill it