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.
You should check out Nix the package manager, which is an even better option than Distrobox if you want to install stuff independently of your distro’s packaging system. The biggest advantage of using Nix is that there’s no container layer, so you’re running the binaries directly on your host OS - this means that the binary can have full access to system resources, which is handy if you need to run one of those apps with root privileges (try running a Distrobox exported app with
sudo- it won’t work). Or say you want to install something like a terminal emulator - it’s not exactly practical to install it inside Distrobox, because now every time you run the terminal, you’d be viewing at your system from inside the container, which can makes things pretty messy.Another advantage of Nix is that because you’re dealing with actual binaries and not just a shim script, it can handle command line arguments properly and also handle things like stdin/stdout properly. In fact there’s a bug right now with the way Distrobox export handles command line parameters, where it eats some of the parameters so your exported program may not work correctly. I had this issue with a Distrobox export of freerdp and raised an issue for it, but it still hasn’t been fixed. So until this is fixed, I’d advise staying away from running distrobox exported stuff, unless you’re using it for only simple apps/workflows.
Also, you don’t have the hassle of having to maintain/update the Arch or whatever OS is installed inside your containers.
Finally, with Nix you can easily roll back your transactions or switch between multiple versions of the apps - all of which takes place instantly, because all it’s doing is switching the symlinks in the Nix store.
With Nix you have to do everything the Nix way. If a package doesn’t work correctly or is missing you either have to dive deep into the Nix rabbit hole or wait till someone who knows stuff fixes your problem. With nix everything is all or nothing (even more so with NixOS).
Distrobox is the opposite, it embraces variety and gives you as many options/distro environments as it can. Once the missing container bugs are fixed you are dependent on no one to get your packages working.
Also, Nix is usually not the normal way devs package their software, so there always have to be people repackaging the stuff with nix (and updating when the source package changes).
Distrobox gives you access to the environment where the stuff is packaged already, a lot less work is needed to get working packages which should not be underestimated.
The more packages you install with nix the higher the probability you encounter packages no nix expert has cared for recently
deleted by creator
lots of softwares are missing in nix. distrobox with AUR is the best and safest option
Any examples of what’s missing exactly?
deleted by creator
yeah, that is why distrobox is lot of more flexible than nixos and hell even SteamOS support distrobox natively as well.
Why not switch to NixOS and run Duplicacy in an Arch Distrobox on top?
I just use distrobox on NixOS.
The whole point of Distrobox is the you want access to the package manager ( well, the packages ) of a different distribution.
Yes, but if that’s all you’re after then it’s overkill, because Nix (probably) has all the packages you’d want. Unless that distro you’re after has a special/unique package that’s not found anywhere else or something.
According to Repology, Nix has around 90,000 packages, compared to AUR’s 75k. Of course those numbers aren’t exactly comparable given the loose definition of a “package”, but it should be a rough indicator that surely you can get almost anything you want from Nix, without running into the limitations and complexities of Distrobox.
complexities of Distrobox
they unironically say in comparison to the arcane language of fucking Nix, lmao
I was referring to the use of Nix the imperative way, as opposed to declarative which requires writing a config file. In the imperative way you can install/upgrade/uninstall packages with just a single command, similar to other package managers.
Eg:
nix profile install nixpkgs#tealdeer-> installs tealdeer from the nixpkgs repo.I’ve been using Nix to install stuff this way on my immutable OS for about 6 months now this way and haven’t had any issues. And it’s fast. Like, even faster than pacman, which is one of the things I like about it.
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 :)
We stopped doing this a few versions ago, main reason was inconsistency between the deck and desktop branches, since deck needs to be properly layered due to it essentially being a desktop environment.
Additionally, we’re not able to offer HDR or steam input with Wayland through distrobox. That being said, bazzite-arch remains a distrobox image with real utility for other use cases and we continue to maintain it.
We stopped doing this a few versions ago
And how are you deploying Steam now? Any chance for easily discoverable documentation about such things?
It’s layered into the image like any other rpm. Standard steam package you’d install in Workstation.
It’s layered into the image like any other rpm. Standard steam package you’d install in Workstation.
Good, considering Steam updates itself anyway.
How long have you been using distrobox and which were the biggest painpoints yet?
I’m leaning, tendentionally, more towards the tech enthusiastic normie side.
I don’t have experience in programming or professional working in IT in general. I just like Linux.
I used it for following stuff the last few months:
- Minor administrative tasks of my home server (ssh, etc.)
- Executing scripts
- Flashing CustomROMs onto my phones a few times
- Accessing/ modding the phone, e.g. debloating or ADB
- Exporting an application to desktop if the flatpak doesn’t work, e.g. Nextcloud client (Flatpak was unlegible due to Qt/GTK)
- Trying some nieche apps, especially from the AUR or in collaboration with a dev on GitHub
- and some more things
The only problems I encountered were probably due to my immutable host distro, for example because of missing folders. Many programs want to access/ change some binaries, which don’t exist, because they are behind /var/bin/…/ and not /bin/…/ for example.
When I used the normal Fedora on one device, and the Atomic on another, one program did work on the mutable (in a Debian container), while the one on Atomic (same container) gave me errors.
Thank you for the answer
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.
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.
@pl_woah @Guenther_Amanita I regard these all these things as nerd toys for exploring innovation …
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
Any recommendations for a rolling-release immutable distro? Or does that not matter?
I haven’t distrohopped in a while and I just might after hearing about Fedora Sericea (Immutable Fedora with swaywm). I just need to understand this whole immutable thing more, because I kind of get the idea but I don’t understand basic things like how to install packages, for example.
Also, any way to install packages in an environment and not have it create config files in your home directory, but instead in a temporary directory? Like when you wanna test software but have to clean stuff up later, it’s annoying
I can make a post similar to this one here about image based distros if you want.
I think Fedora Atomic (Silverblue, Kinoite, Sericea, etc.) are the best choice atm.
It’s the oldest and most sophisticated one and gives you the most choice.
Take a look into universal-blue.org if you like ease of use, want more DEs/ WMs than the few official ones, or have special hardware (Nvidia, etc.).NixOS isn’t immutable/ image based per definition, but even if it would, I personally would only recommend it to highly skilled people who have the time to work themselves into it. It has its benefits, but sounds like a lot of work and is very complicated due to lack of documentation.
OpenSuse Aeon is pretty new and doesn’t have a big dev team behind it, and therefore I wouldn’t trust it enough yet.
VanillaOS sounds also very promising, but is very immature atm and also has a small dev team.
It will be Debian-based very soon and wants to be a future-oriented Linux Mint alternative. Same philosophy (ease of use, stability, etc.), but different approach.
Sadly you are stuck to Gnome and can’t rebase to something else, which is a no-go for a DE-hopper like myself.
But I am very interested in its future and will try it some time.
About installing software:
- Choice #1 is Flatpak. It’s simple, usually just works and is for everything graphical. It covers 99,9% of everything you want and need.
- Choice #2: Distrobox and Nix, especially for CLI stuff. It’s a bit more complicated than just hitting the install-button in the software center, but if you need that stuff, you are already used to work in the console anyway.
- Choice #3: Direct install. I use Fedora Atomic as example here. You can still use your package manager (similar to dnf) and layer the packages. In practical use, it is the same as installing it traditionally, like with apt or dnf, but under the hood, you can imagine it like Gnome shell extensions. They can add, change or mask features the UI, but it’s still Gnome and one toggle away. OSTree-layered packages are still separated from the base, but work exactly as if they would be installed on bare metal.
So you never loose any functionality, only some things are a tiny bit more complicated and different. Once you got it, you don’t see it as impractical, but genius.
Nice, I use SwayFX so Fedora Sericea is (almost) perfect, I’d just have to rebase* to SwayFX.
*I don’t know what exactly “rebase” means, is it like a command that replaces your base system? If that’s it, then awesome!
Is it possible to use any DE if I install a base image (one without a DE) then just install the DE via OSTree? I haven’t found any SwayFX images.
I’ll stick to Void Linux right now, though in the future I’ll probably switch to Fedora Sericea or NixOS. Probably Fedora first and in a later future, NixOS, since I like its features but don’t understand them yet.
I don’t know what exactly “rebase” means, is it like a command that replaces your base system? If that’s it, then awesome!
Yep, exactly that. Simplified, there’s only “your stuff” (mostly /var/ and or /home/), and then there’s “the OS”, which you never interact anyway and is only there to make everything function. Similar to Android.
And when you rebase, you swap out “the OS”-part, but keep “your” stuff.It’s like a clean reinstall, but you don’t have to download your Flatpaks, type in your WIFI-password and copy your photos again. Everything else is fresh.
Is it possible to use any DE if I install a base image (one without a DE) then just install the DE via OSTree? I haven’t found any SwayFX images.
Yes and no.
There is a core image (no DE), yes. And you can install the WM with OSTree too, yes.
But, no. You don’t do that. OSTree is basically only there for your individual stuff that needs the privilege of the base system. TLP, drivers, such things. For everything else, it’s the last resort.
But don’t worry. Here comes the best part: you go to universal-blue.org and create your own image.
You basically use the blank template and tell the “build script” which packages to use.
And then, you can use this custom image, which will be automatically updated by automatic Github build actions. It’s basically a spin/ distro you don’t have to maintain yourself.
You can try it, it is actually pretty easy. I will do the same soon, and I’m a noob in contrast to you! :)On traditional distros you have a down-to-top approach, and on immutable ones, a top-to-down. If you want to make bigger changes, you change the image, not your install. Both are customisable, but the one takes another approach.
If you decide to make your own DE-spin, please contact the uBlue devs, so they can add your image to the official list.
If you do that, others can use it too and have the exact same install as you :)But don’t worry. Here comes the best part: you go to universal-blue.org and create your own image.
this has blown my mind! it’s here i’m supposed to go, right? the only problem i have is with github, since i have moved my stuff to codeberg and this looks way too dependent on github specifically.
i think i might either try Sericea (sadly just default sway, not swayfx) or use NixOS. this is because i don’t want to have to learn too much at once, as that tends to be confusing and frustrating.
Update: I installed NixOS on my laptop (secondary pc) to learn it. Took me all day, but tommorrow I’ll maybe make a dotfiles repo using flakes.
Here’s a starting point I found for doing exactly that: github:Misterio77/nix-starter-configs.
My solution is to create the distrobox with its home directory in a temporary subdirectory. Works pretty well!
I’m using Fedora Kinoite.
I’ll try that out. Didn’t know you could do that!
Yeah, it’s really neat! I can especially recommend using
distrobox assemble, which allows you to store all options in an INI file. Way easier for testing.I wrote a script that calls assemble, and after that does some initial setup (that I couldn’t get working with init scripts). If you want to do the same, use the
--no-ttyflag ondistrobox enter:)
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.
Why has nobody ever heard of Distrobox?
Because there’s Flatpak.
Flatpak doesn’t work well for non GUI apps. I use distrobox to compile software or install nodejs.
Maybe you should be using Docker/Podman for that?
Distrobox runs in Docker/Podman. Why use the tools manually, when there is a nice and useful wrapper that adds functionality?
Because less overhead. Less things to break.
How so? If I replicate the setup that Distrobox gives me, I’m much more likely to make a mistake and add bugs. I also won’t receive any of the bugfixes from the project. This makes breakage much more likely.
Also, less overhead? It’s containers, just like what you’re proposing.
That’s what Distrobox is
Flatpak is only for graphical programs
And the only distros that actually matter are Debian and Red Hat Enterprise, so wtv.
deleted by creator
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.
**The answer is simple: use fucking containers. **
Ha ha ha ha ha. Oh summer child.
If you’re gonna dismiss it like that then I’d love to hear what your pain points are. What’s so bad about containers for multi-platform applications?
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.
deleted by creator
