Linux containers have made it reasonably easy to develop, distribute, and deploy server applications along with all the distribution dependencies that they need. For example, anyone can deploy and run a Debian-based PostgreSQL container on a Fedora Linux host. Distrobox is a project that is designed to bring the cross-distribution compatibility to the desktop and allow users to mix-and-match Linux distributions without fussing with dual-booting, virtual machines, or multiple computers. It is an ideal way to install additional software on image-based systems, such as Fedora’s Atomic Desktops or Bazzite, and also provides a convenient way to move a development environment or favorite applications to a new system.
Distrobox creator Luca Di Maio was inspired by the Toolbx project (formerly Container Toolbox) for Fedora. Generally, the idea with Linux containers is to run processes in their own environment to isolate them as much as possible from the host without having to resort to virtual machines with their additional overhead. It is possible, though, to set up a container to give it privileged access to the system with little to no isolation. This is typically referred to as a privileged container. It is possible to set up privileged containers manually, but it requires the user to know a great deal about working with containers and some fairly involved setup. The original goal for Toolbx was to let users run a privileged container “toolbox” on image-based systems that could be used for system administration and troubleshooting without having to include administration utilities in the image itself.
This is an LWN Subscriber link I provided from my personal subscription, if you like this kind of content from them I’d like to encourage you to subscribe to one of their plans and support them, the cheapest one is just 5$/month
You must log in or register to comment.
The AUR package for Cisco Packet Tracer is borked on Arch, so I tried out Distrobox for the first time, spun up a Ubuntu container and set it up there.
Worked great, I’m quite impressed!Check out ptyxis as well. Terminal with support for opening new tabs into the container namespaces.
Honestly tinkering like this is a lot more stable for me. If I bork it, I can just blow it away. I just need to get better about going from tinker to full Containerfile for my build environments lol
Interesting project, but not pulling me off XFCE terminal.
The name sounds like a Romulan senator, though.
This one? https://gitlab.gnome.org/chergert/ptyxis
Seems really cool, thanks for the tip!
Gonna have to stop you here and downvote this…this is a horrible idea for a lot of reasons.
-
There is a reason that a “distro” is a distro. All the components fit together and make a cohesive environment. Providing privileged access to whatever the base is to operate as if it were simply some tool running will 100% break the host OS in time. It’s not even a question.
-
The abstractions of tools in tools on top of tools is just stupid. The effort needed to manage, recognize, and log where the interactions happen is just absolutely insane.
-
Simplicity in operation ties into #1. New users would have no idea WTF is even going on here, would find no docs to help them if they run into trouble, or find any other users who are running the same combo of stacks-on-stacks to be able to even attempt to help them out. Advanced users would be able to just pick up a tool from one distro, and drop it another. Makes no sense in either case.
-
Recovery: should something bad happen, you’d have ZERO way to even attempt to fix it. Again, containerized tools would be make operative changes to the Host OS, and any tools with the Host would be useless to repair them, because they’d only be expecting to work within their own ecosystem…again, what makes a distro distinct.
Here’s a simple example: I run whatever Host OS, and then I go and run another container OS that intends to operate on my Host, BUT, it’s missing a GCC version that is expected. You poke around a bit, and in an attempt to solve for a missing dependency, now your host gets an incompatible GCC version installed into itself and gets borked.
No coming back from that in any simple way.
Again, who is this intended to appeal to?
Edit: Also, just reading the end, this is like Homebrew with extra steps and more stupidity.
I can’t tell if you’re trolling or just completely uninformed. Which is it?
This is a dramatically misinformed comment. You have clearly never used Distrobox.
-
The first bullet is the worst. This is like saying that Flatpak will break your host. It will not break the host OS. Learn what a container is.
-
It is not tools on top of tools. It is tools in a container that you can optionally create entries for in your app menu. Apps in the container execute directly on the host kernel in the container. If you are in a shell, you are either in the container or out and the full environment will reflect that.
-
It is not for “new users”. That said it dramatically simplifies many intermediate ones and make some advanced things possible. Once again though, there are no “stacks on stacks”.
-
The exact opposite. Containers do not change the host. If something goes wrong in the container, you can purge it completely without impacting the host.
In fact, one of my core uses for Distrobox is to keep my host system clean. I use Distrobox to setup dev environments, to try out new software, to work around Distro constraints, and a host of other tasks. It is great.
There seems to be quite a fundamental misunderstanding of what a container is. Everything runs directly on the host kernel. Apps outside the container run on the host OS and do not interact with the container. Apps in the container run in the environment inside the container. The only interaction apps in the container have with the host is the kernel, the filesystem, and via servers like Wayland, Pipewire, and XDG portals.
The entire point of a container is to create an application environment that looks exactly like an application expects regardless of system it is running on. It is clean and consistent between deployment. This is the exact opposite of what the above comment implies.
In practice, it “feels” like apps in Distrobox are running native on the host OS but in fact everything above the kernel is running inside the container and each container is distinct from the others.
The “example” is totally wrong. GCC is either on the host or it is not (from the host). GCC is either in the container or it is not. They do not interfere with each other. They do not even share C libraries. However, the can see the same source files.
Distrobox is absolutely nothing like Homebrew. Homebrew is a package manager. If you are using a package manager in Distrobox, it will be the one intended to work with whatever distro you are running in Distrobox. This is a fantastic illustration of the confusion of ideas at work here.
If you have to compare Dostrobox to something, compare it to Flatpak.
-
Valid points but it actually works pretty well. Give it another go and you may be surprised
I don’t think there’s a single valid point in that comment
deleted by creator
It is not about how well it works. They can certainly disagree about that.
The problem was that they clearly have no idea how it works and “warned” people about a bunch of things that will not happen.
If posted a comment about Linux and told you not to use it because it would cause your hardware to disintegrate, the issue is not my level of Linux advocacy. The problem would be that I am peddling actual falsehoods.
-
