toolbox is preinstalled on fedora silverblue/kinoite whereas distrobox isn’t. What’s the advantage of one vs the other? Why is toolbox preinstalled and not distrobox?
edit: thank you guys! I guess for me this means that I’ll use distrobox because it’s much more mature or documentation is a little bit better and I do not need (or have) fedora’s support
Why is toolbox preinstalled and not distrobox?
Because Toolbox is a Red Hat/Fedora project and Distrobox isn’t. Also, Distrobox is a much more recent project (2021) compared to Toolbox, which was developed back in 2018. When Silverblue came out, there was a need to make it easier to install apps, and thus Toolbox was born.
Since Toolbox is a Red Hat/Fedora project, it means that it’s officially supported, whereas Distrobox isn’t. Not that it means much from a community support/home use case of course, but that might matter if you’re an enterprise and you want support from Red Hat or official Fedora communities.
But both use podman behind the scenes so internally they aren’t that different, but you can think of Distrobox as a more distro-agnostic and user-friendly version of Toolbox. If you’re a home user then stick to Distrobox.
Distrobox is directly inspired from Toolbx and was created because of limitations of Toolbx and how Toolbx’ maintainers didn’t want to implement some features at that moment in time.
Currently, Distrobox is almost a superset of Toolbx. Though, I’ve come to the understanding that Toolbx does better at some tasks.
If you would like to stick to just one of them, then Distrobox is probably still the better one and should be preferred. However, if its added functionality doesn’t do it for you, then please feel free to continue using Toolbx.
Why is toolbox preinstalled and not distrobox?
Because Toolbx predates Distrobox and is developed by developers that are associated with Fedora and even specifically designed in hopes of solving some issues pertaining to Fedora’s Atomic distros.
I’m a Fedora user and Distrobox just seems more complete as a project and the commands make more sense to me
I stuck with Toolbox for a long time because it was default, but then I wanted to be able to easily recreate my *boxes with the same set of packages when e.g. they broke for some reason, or because the distro they were built on released a new major version. Distrobox supports that with its assemble command, so I switched. Otherwise it’s not too different really, for a casual user like me, and if I hadn’t needed assemble, Toolbox would’ve been just fine.
(Except that I keep forgetting whether Toolbox or Toolbx is the correct spelling now.)
Damn that toolbx spelling is horrible
deleted by creator
I use Distrobox on Fedora Silverblue.
More precisely, uBlue. It came pre-installed there and I quite like it.Toolbx is more of a “use it to install command line dnf-packages on SB”, while Distrobox is way more capable.
I can have any distro I want as container and export graphical apps and binarys.
All of the universal blue images come with distrobox so I gotten used to that, it’s nice that you can export apps so they appear in the DEs application menu
Can I ask why you choose to use one of those weird “immutable” distributions in the first place, out of curiosity ?
Not OP. But for me, atomic updates, reproducibility, (to some degree) declarative system configuration, increased security, built-in rollback functionality and their consequences; rock solid system even with relatively up to date packages, possibility to enable automatic updates in background without fearing breakage, (quasi) factory reset feature, setting up a new system in just a fraction of the time required otherwise are the primary reasons why I absolutely adore atomic[1] distros.
- I prefer referring to the so-called ‘immutable’ distros as atomic distros instead. It’s more descriptive, because the distros aren’t actually ‘immutable’ but instead they’re atomic.
I disagree with most of the benefits you list (chief among them “increased security”) - not to mention half of them are already supported by traditional package managers - but I was genuinely curious so thanks for the rationale.
Ubuntu, then Debian on my University computers, broken every weeks with dpkg killed while updating (students don’t care properly shutting down computers).
Since we migrated to Silverblue, it just works. We can downgrade the system at any point in time, even previous release. Apps can be individually downgraded, locked at any point in history. Totally not doable with a traditional package manager.
I disagree with most of the benefits you list
I’m curious to hear your objections.
chief among them “increased security”
Do you deny that specific protection to some attacks is provided through the chosen model of ‘immutability’ on at least one of the atomic distros?
not to mention half of them are already supported by traditional package managers
Hmm…,:
- atomicity; nope
- reproducibility =/= reproducible builds for some packages (if that’s what you meant)
- declarative system configuration; ansible (and any other solution that I’ve witnessed being mentioned in such discussions) succeed (at best) at convergent system management, while e.g. NixOS does congruent system management by default. Consider taking a look at this page if you’re interested in what these are and how they’re different. (Spoiler alert) congruent is better and therefore more desirable.
- increased security; security is not limited to chosen model for ‘immutability’ if at all; as Qubes OS (read: most secure and private desktop OS) doesn’t rely on it for its security. So I can understand where you’re coming from, but I have yet to see any non-security focused distro that provides the elevated protection against particular attacks that some atomic distros offer by default.
- built-in rollback functionality; sure, this is not exclusive to atomic distros. Perhaps I should have done a better job at making clear that it isn’t a feature provided necessarily by atomicity. But, the fact that I listed it at the very end, alludes that it isn’t as exclusive and consequential as atomicity is. At this point, however, it has become almost synonymous with atomic distros, while the same can’t be said about traditional distros.
- regarding the consequences; I’m unaware of any distro that does those out of the box (barring Pop!_OS with their factory reset). Though, I’d love to be educated on this.
I was genuinely curious so thanks for the rationale.
It has been my pleasure ☺️! I’m also genuinely curious to read your reply to this comment😉.
I really wanted to avoid a debate (doubly so in a thread where some dude just wanted some help), which is why I’m trying not to engage the various answers I got; though just one thing since I apparently can’t help myself: Qubes, which you cite, is indeed an example of such improved security done correctly, through an hypervisor and a solid implementation; not cgroups, some duct-tape and the same kernel, and thinking your security has improved. Thanks again, at any rate.
Understandable! Please consider coming back to this at some point (also possible in private) as I’m genuinely curious to hear from you.
There are may layers of security that every companies have different approach based by their users / their target customers.
All of the points of the previous comment are actually valid. Plus, immutable distros are much safer and easier to tinker with than traditional mutable distros. For example, an extremely specialized Arch setup would be much more stable and easier to jumpstart if it was a personalized Universal Blue image, even all your Flatpaks can be declared and installed at setup.
sure,
I already liked fedora for choosing sane (imo) defaults for the most part. I got to know the atomic builds just a few weeks ago. The advantage the atomic versions have over the traditional builds are that they are reproducible which is huge advantage for maintainers. Hence, it’s not directly an advantage for me but reduced workload for others.
The update process is much easier than with workstation as you just have to restart the system “without having to update”. It’s like android in this case, you just restart and have an updated system. Moreover, I can just switch to another system underneath without breaking the rest of the system. Although it might be better to have an additional layer in between the base OS, the DE and (graphical) applications.
Moreover I really like the idea of having reproducible systems, i.e. I can setup a working system with e.g. distrobox and distribute it to others. I have not yet used this but I like the idea behind it. This is not distro dependent but the atomic versions made me aware of it.
And I appreciate that there’s always a working system. There are other ways that can ensure a working system but it works very well (so far) and is directly integrated into the OS.
Not OP, but for me, the main benefit is how uneventful major distro upgrades are. Yesterday I updated to Fedora 39, and it was so anticlimactic to reboot and then be like: is it over? But that was really all there was to it.
For general usage, it doesn’t really matter. Distrobox is inspired on toolbox and provides some added functionality and configurability, like init scripts and the ability to run different distros, as well as creating desktop shortcuts on your host system. If you don’t need all of that, I’d stick with toolbox, as it’s preinstalled and works well.
Distrobox was always stable for me. Autocomplete only in bash but that doesnt matter much. Waaay more images by default but not as curated, also many are maintained by Fedora people and not the Distrobox people, so its not like they actually support more but just ship.
This is a big difference, Toolbox also supports these images.
But featurewise distrobox is brilliant, love the app icon export, the binaries are maybe a bit bloated.
Why not both ? Toolbox is the fedora/redhat solution, which is the why, and makes it the choice when something’s in the fedora repositories, or if you want to trial it before (considering) rpm-ostree install, but an Arch distrobox gets you the AUR, not to be sneered at…
I use toolbox: Distrobox is a pretty horrible shell script and deleted parts of my home directory when I tried that.
In the end I just pointed toolbox to a script named
podmanthat just adjusts the setup to what I need, implementing the missing features I wanted that way.
