Docker Agent could be beneficial for research studies. For example, while writing a ML paper about agents I need to rerun experiments so that:
- others can repeat my results
- validate that variability from LLMs is not causing overconfidence in the results
But currently uv is good enough to create isolated, repeatable environments. And it isn't limited to Linux like standard Docker. So when I want to test small samples on my local PC's GPU (Windows or mac) before running on beefier hardware, I can do that easily.
they hope they can annoy and email every person in the org asking for money , same way as they did it with docker.
looks like a weird abstractions. why do i need this if i have modal.com, e2b, cloudflare that use original docker + some toolings around + way to run + isolations on network level.
It frustrates me that there's a prisoners dilemma in communicating this to other humans. If I flag it and write it out (as you've done) I've let the author know that they're losing trust and let others know that they should be more skeptical. I've also created the perfect eval data pair for the ai labs. It's deeply frustrating.
You don't really have to use the docker agent sub-command. docker-agent is a standalone binary. When it was created, though, 1.5 year ago, the idea was that it would be the docker compose for agents (original name was cagent, compose for agents).
But it evolved differently and although it runs very well in docker containers and docker sandboxes, it also runs very well anywhere else.
It was created to be the docker compose for agents. 2 years ago, people, including ourselves, started to mix agentic loops and non agentic components in docker compose files. We created docker agent to make this more powerful.
At the end, the link with docker compose is just the yaml form. Which by the way can be replaced with hcl files or Go code.
Docker Agent predates Docker sandboxes. It was created almost two years ago when not everybody had a AI harness. Nowadays, it does run very well in Docker Sandboxes but it runs also very well anywhere you like.
Nowadays there are only two justifiable public languages you should be using for anything
a) C++
b) Rust
Rust itself is dubious due to abysmal compile times and the fact that the only guarantees it gives you are of security (aka a skill issue). Modern LLMs write C++ that is as safe if not safer than Rust. Any other language choice is objectively wrong.
* For those inquisitive enough the keyword "public" is doing all the heavy lifting here. Pretty much everyone should be developing and using an in-house DSL at this point.
If, like me, you couldn't find any security-related info on the linked page.
But currently uv is good enough to create isolated, repeatable environments. And it isn't limited to Linux like standard Docker. So when I want to test small samples on my local PC's GPU (Windows or mac) before running on beefier hardware, I can do that easily.
All the cool kids have one!
looks like a weird abstractions. why do i need this if i have modal.com, e2b, cloudflare that use original docker + some toolings around + way to run + isolations on network level.
Yep, open ai sol model wrote that.
Having it docker branded, I could understand. It’s confusing but the docker brand is strong.
But exposing it as a docker subcommand is very confusing to me.
But it evolved differently and although it runs very well in docker containers and docker sandboxes, it also runs very well anywhere else.
It is called 'Docker' as the company, and it has nothing to do with the container technology.
At the end, the link with docker compose is just the yaml form. Which by the way can be replaced with hcl files or Go code.
Nowadays there are only two justifiable public languages you should be using for anything a) C++ b) Rust
Rust itself is dubious due to abysmal compile times and the fact that the only guarantees it gives you are of security (aka a skill issue). Modern LLMs write C++ that is as safe if not safer than Rust. Any other language choice is objectively wrong.
* For those inquisitive enough the keyword "public" is doing all the heavy lifting here. Pretty much everyone should be developing and using an in-house DSL at this point.