Hi there!
I don’t know if there’s already an official thread about this, and if there is I couldn’t find it…
So, for the time being, I propose to start a discussion about the pros and cons. I’d like to hear opinions from people who know more than me about why/why not.
For some time there has been some discourse about switching from toolbx to distrobox.
Personally I’m for the switch, since distrobox is the tool that’s being adopted by other distros (MicroOS, Vanilla, etc…) and, in my experience, distrobox has been far more reliable and useful to my workflow in Silverblue.
What do you think?
1 Like
Having replaced toolbox with distrobox completely for a few weeks, I can say that distrobox is a straight superset of toolbox.
All the tiny edges I cut myself on with toolbox are gone, things like ephemeral containers are much easier, using a different $HOME is trivial, being able to call out to host programs, being able to compose containers, the containers having unique host names, I could go on and on.
I really think this is a productive discussion to be had across Silverblue, Kionite & Sericea.
4 Likes
Thanks for your input! I completely agree with you!
I wonder if there are any real issues at all that prevent Silverblue (and friends) from making the switch
1 Like
In my eyes the issue is that it’s simply a big change that users depend on, so phasing it out when there’s not a complete 1:1 in terms of CLI API is something not to be rushed.
Interested to know if there are other reasons though.
@buonhobo , If you are so hot on having this you could package it and submit the package to be included in Fedora repo. I wouldn’t recommend removing toolbx though since it is in quite a bit of use by many, and it is pretty small as a pkg goes I think. Plus, in my case I prefer toolbx over distrobox.
The distrobox package already exists in the fedora repos. The thread was about discussing the possibility of transitioning silverblue from toolbox to distrobox.
I know it’s used by many, but that’s mostly due to it being the default choice. The switch doesn’t have to happen overnight and it could happen over one or two fedora releases.
Toolbox has a really slow development, a much smaller set of features and many sharp edges. Distrobox is being adopted by all other immutable distros so it would make more sense for the most popular option to be the default one
I still prefer toolbox and since distrobox is available in the repos then your point is sort of moot. Personally, I don’t feel it is necessary to replace toolbox though, and especially not for a thin reason like “everyone else is doing it.”
One thing that kept me from switching to ostree spins/(tool|distro)box is the somewhat surprising state of isolation (or my wrong expectations thereof): toolbox isolates its inside from your host system (different /usr etc) but not from your $HOME. Yes, I know why, but it means:
- Any app you run in your toolbox has full access to your “data”, just like any app you run on your host has. We should avoid giving any false security when we market this.
- Anything in your toolbox sees your full environment (variables) but not your host’s system installation. In particular, typical cli setups (be it yourshell.rc sourcing system rc files, env variables such as PS/PATH pointing to system paths, anything referring to executables in your system installation) trip over the fact the system
/usris not available inside the box.
Does distrobox solve any of the problems which toolbox has in this regard? Can, say, my .bashrc at least detect whether it is sourced by the system shell or the one in a box so that I can make it behave differently?
This thread can serve a valuable purpose if those who know their favorite box give technical insights on the differences (rather than personal preferences, it’s nothing to vote upon as we have both).
By this, do you specifically mean the fact that your $HOME becomes the same as the containers? If so then yes, distrobox lets you set an arbitrary folder to act as that. If not, then please elaborate 
That’s still the case, they both use the same strategy there; but one thing you can do is alias commands from the host to the container to let you run host commands inside the container.
That’s already the case now, if [ ! -e /run/.containerenv ] && [ ! -e /.dockerenv ]; then will check if you’re running in a container or not, in the case of distrobox it also generates a unique hostname of <container-name>.<full-system-hostname>.
I agree, this is an important distinction. Fundamentally, they do the same thing. Distrobox just offers a superset of features in comparison, and development moves a lot faster (in the sense that issues that are plaguing toolbox have been long fixed in distrobox)
Funny that you all think the same. Distrobox and Toolbox use different languages, but work similarly. Distrobox is nearly perfect in its tooling, and just saves so much trouble.
It works just as reliably, I guess, as I ditched toolbox a while ago.
On Kinoite I now have
- Dev Ubuntu container for adb, compiling stuff and using the PPA VLC 4.0
- Fedora Container for RStudio (+ COPR for modules), QGis and others
- Debian testing container for Ardour
- Arch container including AUR
- Opensuse Leap container for weird old programs
It works as a charm. GUI integration of packages is no problem, CLI integration too.
See Tips and Tricks :: Fedora Docs for some examples.
1 Like
distrobox is a fork of the original CoreOS toolbox with some extra capabilities.
Ideally, someone who uses both should talk to the Toolbox project about getting the extra features integrated into Toolbox, so that the projects can re-unify.
The issues I’ve previously mentioned are on-going issues in toolbox that see little to no movement.
I’m also not convinced it’s a fork, since one is a set of POSIX scripts and one is a Go suite.
1 Like
I don’t know the full history / origin story for distrobox but toolbox used to be a shell script too.
I see, thanks for the correction 
There’s also the fact that, from what I understood, Toolbox was rewritten in Go as the maintainers started to find the shell script unmaintainable. This leads me to think it would be better to expand the scope of Toolbox rather than switching to Distrobox.
1 Like
This should be on the discussion area not in askfedora.
I moved it there but we lost some tags.
I think that the main difference is that, while toolbx expects docker images built for toolbx, distrobox patches the standard images on creation. Thus, distrobox is able to support more distros. Since it means less maintenance on distro builders, it’s a more widespread solution.
Besides, it has an option to create a destkop entry of an app installed inside the puppet container. That’s awesome.
I’d love to see that replacement.
Distrobox is a shell program/series of shell programs, whereas Toolbx is written in Go. Toolbx never used Docker, it was always Buildah/Podman/Skopeo originated. It (Toolbox/Toolbx) is an OCI container image creation tool. Distrobox is very much an adoption of the original Toolbox idea, which was shell based at the beginning. I agree with @siosm that it would be more logical to create issues in our community to have Toolbx (Toolbox) to be feature on par with Distrobox at least, but more appropriately start to lead again in this area. Any Go programmers in the community that use these tools willing to help? Where Toolbx lives.
1 Like