Why DX instead of distrobox?

So, question to the crowd, I’ve gotten use to the distrobox dev workflow, and I likey, muck around, archive, blow away and start again, what does DX bring to the table? Both Bazzite and Aurora, it almost seems like a backwards step, perhaps it facilitates dev adoption, but they’ll soon run into roadblocks and frustration, why not consolidate on the main images and have ‘DX’ distroboxes to get people started and focus on education to the container way ?

I presume (hope) there is a good reason, and as I consider moving to one of the DX images, I’d like to know what it is…

1 Like

DX is just bringing some more tools to the image like docker, vscode and qemu/libvirt.

We are also planning on retiring DX images and handle those stuff with homebrew

4 Likes

Cool, thanks, I’ll stay where I am then. Personally I’ve embraced podman over docker (which is admittedly more generally used), there’s some setup overhead, but maintenance is easier and security is better. I like a vscode per project in distrobox, even if it’s a bit wasteful, space is (used to be, sigh) cheap. I’d layer qemu if needed, but podman meets my needs. I should look at homebrew again.

1 Like

FWIW, I rely on both (for now). I have a custom distrobox setup (a layer of tools to make creating multiple distroboxen more simple). And was relying on both docker and podman so I could properly encapsulate my development envs (in docker) vs system needs (in podman).

I have written up the rationale behind all of this at klmcwhirter/oci-shared-images.

But am watching for what @infy is mentioning to be finalized …

I do make use of brew for things I always want on my host - like uv (latest version), etc. But for complex tool chains I like them in their own container - e.g., the tools needed to compile my own python 3.14 and math modules that rely on C extensions that need to be compiled. There is an example of that in Containerfile.fedora-python314 from the repo above.

FYI - once the move to brew has been completed I plan to drop usage of devcontainers and the ublue toolboxes. At that point my plan is to rely on brew and `quay.io/fedora/fedora:43-x86_64` (Fedora distrobox base image) using only podman.

  • the devcontainers ecosystem is just not maintained well enough for my needs. The templates and features have been too far out of date each time I have tried to use one

In short, I like having the options bluefin-dx makes available for experimenting with my own personal policies.

There is no ONE right way.

The best way is a matter of personal preference and takes some exploration to fine tune. The good news is that bluefin (in dev mode) has all the options I need to explore away to my hearts content.

My $0.02.

-k

Sounds like a plan. Less images to maintain.

1 Like

Can homebrew replace root docker and libvirt?

1 Like

I bet they just put those back in the main image

2 Likes

Is there a way to follow to work being done for that?

This is the tracking issue for it

1 Like