TL;DR: It’s basically a WSL for Linux. Linux subsystem for Linux if you will.
It let’s you install and use pretty much any software ever written for Linux, including AUR packages and graphical apps, on any distro you want. You should all give it a try!
Distrobox is probably the best thing ever.
If bread existed in the Linux world, Distrobox would be the equivalent, or better than sliced bread.
It just solves many of the problems that plagued us in the past!
I’m just sick of answering so many comments or posts where people either
- almost dislocate their joints in trying to get some software working on their distro, where it isn’t officially supported;
- or choose/ leave a particular distro based on the amount of available packages, e.g. Arch.
**The answer is simple: use fucking containers. **
Before I turned into a weird “immutable distro”-user, I slapped every random install onto my host OS.
After all this shit building up over years, and cluttering my system, it turned against me.
Repos not being available, packages conflicting, weird icons popping up, and more. It was a mess!
If one did that on a server, he would probably get slapped by the Selfhosted-community.
If there’s Docker, Podman and more, especially for servers, why don’t we use it for desktop too?
Some guy probably thought the same and made Distrobox.
You can just download BoxBuddy as Flatpak and/ or install it via package manager.
BoxBuddy is a graphical frontend, that helps you manage and use your containers. It’s pretty new tho and is still in heavy development.
Traditionally, Distrobox is CLI-only, but I can see that changing in the near future.
“Why not just use a VM?”
Those containers aren’t isolated and barely draw additional resources. Actually, they’re somewhat comparable to Flatpaks.
They provide themselves with their stuff they need, but aren’t virtualized. The main difference between Flatpaks and DB-containers for myself is that Flatpaks have permissions.
They can and will interact with your host. For example, if I plug in my phone, I can access it via ADB in my Arch container. Or my Nextcloud-client can open my browser and auto start on boot.
Who needs that?
Everyone. Well, maybe. Depends.
Image distros
Certainly users of image based (“immutable”) distros like Fedora Silverblue and other variants of this family, like uBlue (Bazzite, etc.).
While we actually could install every package from the Fedora repo traditionally on our host, this should be avoided.
Steam Deck users would benefit strongly too, since they can only use Flatpaks atm.
People who can’t get some packages with their distro
One of the main arguments, why so many users go or stay on Arch, is the AUR.
Often, they have a love-hate-relationship with it. It might break easily if you do something wrong, which is easily done for many users. At the same time, it gives them their niche software they need.
What if I told you, that you can enjoy this huge plus point for Arch on every other distro too, while benefiting from the comfort of your favourite distro?
You can even install an Ubuntu container and use Snaps there if you enjoy using them.
Developers
On the stock Fedora Silverblue, there’s Toolbx pre-installed, which does something very similar, but not as good. It’s a RedHead product.
On uBlue on the other hand, Distrobox is the default, which is better.
Toolbx’ main use case is programming. For devs working with different Python-versions for example and don’t wanna risk breaking their OS.
DB does the same, but more.
But why is it so powerful?
You can also export your software to your host.
E.g., the Flatpak version of Nextcloud didn’t work well for me. The Arch package on the other hand is less buggy and looks properly.
It’s perfectly integrated in my system and I don’t notice it at all that it hasn’t been installed natively.
This even extends to DEs and TWMs!
You could, for example, create an Arch container only for Hyprland, which you basically can’t install on other distros.
And then, you can use said example, or the beta-version of the new Plasma, on OpenSuse Leap.
On uBlue at least, all my containers update themselves too.
Another great thing is the modularity.
You can, for example, just delete the Arch container if it breaks randomly or due to user error, without worrying about losing access to your PC or having to troubleshoot for hours.
All in all, just try it. Trust me.
I have seen many people on Lemmy mentioning Distrobox, who are you referring to?..
Also, yeah, it sounds neat. Thanks for the good post
I’m not refering to any comment in particular, it’s just that it happens all the time that someone doesn’t know about that possibility.
I’m reading all the time stuff like “If you need this package, then the only option for you is Arch” or “I’m on Arch and can’t install this Fedora package, I have to compile it myself”, and so on.Yeah, there are people mentioning it, but still, many many others have never heard about it, and I find that a bit sad.
I did an experiment where I used Distrobox for many apps not available on Debian. I installed an Arch distrobox and exported the packages. I found that it works great with simple programs, but I run into a few issues when using more complex programs. Jellyfin Media Player for example tended to have a memory leak and have a core dump on the desktop whenever it is closed. It uses twice as memory as the Flatpak for some reason. I had the same issue with Stremio which is also a video streaming app. For command line things it’s mostly fine. But this too can get tricky. I tried to use Neovim (Debian’s is a bit old) in the Arch distorbox. The issue is that if you need plugins that require some dependency with a given version then you have to also install those and export them which makes things messy. For example you may have a version of Nodejs on your Debian install but you’ll need to install Nodejs on the distorbox too and export it. It’s the same with many packages like that. You’ll run into some issues and waste time trying to figure out where is it coming from. Is it your machine or the distorbox? I ended up just building from source. Overall it’s a great project and might work for some software that you need. But it’s not something you can always rely on for everything. The app devs are not testing for that specific use case. It’s so great for testing and installing stuff and then destroying when you don’t need it anymore.
Distrobox: If AppImage isn’t already enough overhead for you, just install an entire Linux distribution for each application.
The “entire Linux distribution” is very small. It’s only like a few hundred MBs.
I have absolutely crappy internet, pretty much the worst in Europe to be precise, and it only took 30 seconds or so with 5 mb/s speed to download.And you don’t install a new distro for every app, you do that for every task.
E.g., I have an Arch container for every CLI-related (installing custom ROMs on my phone, server administration, etc.) and one Ubuntu/ Fedora one for everything else if I need it.
The latter one is basically unused btw.Yeah, I’m not sure what the hard-on is for containerization.
I’m not sure what the hard-on is for containerization.
Bazzite uses Steam in an Arch-based Distrobox container. The FAQ doesn’t address what the benefits of that over just using Flatpak are.
I also thought about installing Steam in DB instead of Flatpak.
The Flatpak has some weird permission problems for example. If I want to give it access to my application folder via Flatseal, it just doesn’t want to start anymore. Therefore, I have to live with it not being able to create menu entries and not having access to other drives except if I grant it that.
On the other hand, I’m glad it is that restricted, and I want to keep it that way.
The Flatpak has some weird permission problems for example. If I want to give it access to my application folder via Flatseal, it just doesn’t want to start anymore.
You’re already providing better information than the official FAQ but that doesn’t explain why it’s an Arch container of all things, considering that Steam on Linux runs off the home directory and the binary from the package manager is just the first-time download manager. And if a container was to be used why Arch, given that officially only supports Ubuntu LTS, SteamOS as shipped on Steam Deck, and whatever container guest Steam on ChromeOS uses, not “plain” Arch.
Could you give me a link to their GitHub?
I’ll suggest them another description and explanation if you think that I should :)
My take is that on an Arch system I can install anything and I have btrfs snapshots to roll back forkups. I don’t need this added layer of complexity in its current form. If it offered proper and easily configurable sandboxing I would certainly think about it.
(Then again I have a Deb laptop and perhaps I will try this out for Pyradio)
I think one main plus point is that it keeps your system less cluttered.
Even on a “traditional” distro (mutable, like Mint, Arch, etc.) I would try to install all my stuff as Flatpak or Distrobox container. Call me compulsive, but I like my stuff to be organized. In my apartment, I also use drawers and boxes, so why not digitally? Installing everything to the host is like cluttering my flat with spoons in my bed and the toothbrush in the kitchen. Sure, it’s not as easy as throwing everything on the floor, but at least I can find it again and it is less of a hassle to maintain it.
Currently running NixOS with Debian and Arch containers in distrobox. Certain apps in NixOS (e.g. Calibre) don’t respect the scaling in Gnome, but work perfectly via distrobox. Btw, there’s a nice GUI for distrobox called Boxbuddy that works really well.
I already put the link of BoxBuddy into my original post, but still thanks for the suggestion :)
Ah sorry man. I didn’t spot it.
Didn’t know about box buddy. Definitely wanna try it out now
That TL;DR is useless…
Edit: it’s now much more useful, thank you
Thanks for the critique, it’s now edited.
This still doesn’t solve the issue with underlying kernel feature and function compatibility. 99% of the time when I have an issue getting something to work, it’s because of something like my LTS kernel doesn’t support floc(), etc.
This only solves competence issues, it does nothing to resolve the difficult compatibility problems.
- even if I’d go back to arch (or endeavouros) I’d install packages via distrobox. Just because I don’t want to mess with my base install anymore. If it is not important for the system, I don’t install it there.
- atomic distro (the word immutable is outdated because it’s ambiguous)
- on fedora silverblue you have to install distrobox manually because fedora wants to stick to their version of it (toolbox) although toolbox is not as feature rich for desktop usage than distrobox. Opensuse on the other hand uses distrobox (they also use the flatpak version of firefox)
- you don’t need to distrohop anymore because of the package manager. You can use any prefered system and put a distrobox on top of it. This is amazing.
- what’s the best image for distrobox? https://lemmy.ml/post/10368483 I’d say use whatever you want. If you’re on fedora, use fedora until you need a specific package that’s not available in their repo. If you are on opensuse, go for that, just for simplicity.
- although I use distrobox and advocate for it. I am reading about the nix package manager. I’m not yet interested in nixos (maybe when snowflakeos is ready for prime time) but the pacmage manager is worth looking into. How does it compare to distrobox? What’s “better” for general packages?
I mentioned most all of your points already in my post, but still, thanks!
what’s the best image for distrobox?
I’d say Arch (btw). I was never a fan of it and couldn’t imagine installing it as desktop distro, but as container, it couldn’t be better imo. It’s minimal and customizable. I use zsh with many plugins, including the Arch one. I didn’t like pacman’s syntax, and with the plugin, it’s easier (´pacin package´ instead of ´sudo pacman -Ss package´). Pacman is super fast too, and installing stuff takes just seconds.
It’s very up to date and most packages have worked pretty reliably actually!
I am reading about the nix package manager
I thought about it a while ago too, but I find it to be too complicated, outdated and just not relevant for me. For others, it might be wonderful, but I just didn’t have reasons to use it.
Distrobox saved my ass during Computer Systems course I took in college. We had to work with xv6 OS and I for the love of god couldn’t make it compile on either Arch or Debian.
After typing one command to set up an Ubuntu Distrobox container and waiting several minutes, it immediately compiled. Happy days
people get grumpy about containers vs nix vs flatpak and I just wanna say… I’m glad you’re using Linux. yes, you.
Yeah, I see it the same.
Both containers and native packages are a huge strength of Linux, compared to Windows for example.I respect both types.
The one is more efficient (especially in terms of storage), the other one has other benefits. They have both their place.As long as it’s Linux and gets you to your goal, they are all equally great.
Unrelated but also kind of related: check out bedrock Linux. It’s a trip.
It lets you ‘hijack’ a Linux install and then you can use package managers and packages from other distros. It’s magical how well it works.
I have to give a go to bedrock eventually, the concept sounds amazing 😄
It’s very useful! I use it to avoid clutter like Tesseract and LaTeX dependencies; using software that it’s not available for my distro (openSUSE Tumbleweed) nor Flatpak and sometimes to try software that I haven’t used before to test, as in checking its config directories, performance, UI, etc. and install/uninstall quickly to avoid dependency problems.
Note: remember to check your PATH while creating your new distrobox, since distroboxes will try to run your
.bashrcor similar and you will get errors or results you may not want to.Why has nobody ever heard of Distrobox?
Because there’s Flatpak.
And the only distros that actually matter are Debian and Red Hat Enterprise, so wtv.
I think it depends on what you want to accomplish.
I agree Distrobox is perfect for any case you want to use software your distro doesn’t support (you basically setup the target distro into a docker container), or for developers wanting to use different versions of software/libraries without risking breaking the host OS with tons of different packages that might conflict with each other, but I wouldn’t say it can also completely replace the use of VMs.
For example, using a VM is the only way for me to use Linux on my company PC (Windows), it’s easy to get permission to install Virtualbox/Vmware since VMs are isolated from your host and you can cut them out from the company network, it’s an opposite use case than what you would use containers for.
VMs are fantastic to learn, trying the setup of a different distro if you’re distro hopping or simulating multiple machines interacting with each other, you can’t do that with containers.
You can even install an Ubuntu container and use Snaps there if you enjoy using them.
The point of Snaps is that they work on any distro
