Hacker News Reader

Comment by kwakubiney | Hacker News Reader

Why’s it not on Linux? What are the difficulties with that platform?

Linux is available today (Ubuntu): github.com/docker/sbx-releases. Our webpage showing only brew and winget is on us.

For the people upthread who asked about on customization: templates (like snapshotting a running sandbox) and kits (YAML applied at creation like install steps, files, network and credential rules, or define a new agent outright) are the supported path now. It's early but take a look here: https://docs.docker.com/ai/sandboxes/customize/

On MCP, since credential handling was mentioned here: the sandbox sees one gateway endpoint, and OAuth tokens stay in the host credential store rather than in the VM. https://docs.docker.com/ai/sandboxes/mcp-gateway/

All this is early. We're looking at more based on feedback from users like running sandboxes in the background for long-horizon work and a lot more (including what you all raised in the thread here). Keep them coming.

Please consider adding MacPorts support.

Brew is notoriously developer-unfriendly.

How so?

The parent didn't go into any detail. I can. Homebrew has a history of ripping out your foundation underneath you. One day you are on Python 3.8, then next day you are on Python 3.10 and all your packages are broken. MacPorts doesn't do that.

Now, whether you should you be using the Homebrew Python is a completely different question. YMMV for other platforms managed via Homebrew.

I've traditionally used MacPorts for dev tooling and Homebrew for everything else, but with more aggressive adoption of tooling like uv an nvm I'm not sure the different really matters for me anymore.

pyenv has been standard tooling for far longer than uv. depending on package manager supplied Python packages only makes sense if you’re running rhel or Debian or something and your application is packaged/deployed/the maintenance path uses dnf/apt. Otherwise you should always use a venv and use an out of package manager update mechanism. Like, in a broader sense, vendoring dependencies only makes sense if you’re shipping an application, not on a dev box.

This is not about python packages, this is about python itself.

That's what the GP means as well, you can use pyenv and uv to install multiple versions of Python and create envs with whichever version you want to use.

A lot of that is simply formula authors / application devs who don't know what they're doing (python@3.10 and other versions are a thing, and have been for quite a while now, but they're not always used and devs don't always keep track of the version they need) and people not updating their software for years (pythons are on a 5 year cycle everywhere, homebrew included: https://devguide.python.org/versions/ and https://formulae.brew.sh/formula/python@3.10 ).

Python in particular is well known to not be a stable target. For anyone. By design. If you expect long term use of a specific version of code, use a different language. It is not at all homebrew's fault that they're how many people discover that.

Exactly. Same with PHP, MySQL etc… Also they just block old versions and dont let you install them, you have to jump through a lot of hoops to use an old PHP version for example, so in no way developer friendly.

In the end I realized that Brew is a package manager for consumers, and as a professional i should’nt keep fighting it.

I use mise for dev tooling, that way I can have the exact correct version for every project.

Python through brew is the one I expect to be the latest one I use for one-off scripts.

I switched to mise too for all my dev tooling. It just works so nicely for all kinds of ecosystems. I can use the same tool for Python, Node, Java, whatever and it just works.

Quick update: webpage reflects Linux support as well, thanks for the flag.

https://www.docker.com/products/docker-sandboxes/

Looks like they do support Ubuntu.

Is this open source? Can I install this on a non Ubuntu system?

A limited form of it with different syntax comes with Docker Desktop. The sbx tool is not available for non-Ubuntu distributions.

CLI works on Fedora. Been using it daily for ~ a week.

See repo `docker/sbx-releases`. The `.rpm` there has Rocky Linux in the name but works on Fedora.

Reply on news.ycombinator.com