I'm really enjoying Distrobox. With it, I've been able to develop on my Steam Deck and use it as my primary and only device.
The Steam Deck default OS (Steam OS 3) is a heavily locked down variant of Arch with only a couple of writable directories. With Distrobox, I can run an Ubuntu environment from one of those directories, ensuring that when I install SDKs or tools, they're being installed to a writable area of the OS but require no config to change what they think is intended install location.
Can you tell us more about using a Steam Deck this way?
Do you often use the terminal (or something like VS Code Remote extension) to do builds on a beefier machine, or do you do all your development literally on the SteamDeck hardware using tools like Distrobox? And what kind of development do you do?
I ask because I need to get a new laptop, but only for the once or twice per month I go physically to the office, and was thinking a Steam Deck might make more sense than a traditional laptop that would be idle ~340 days of the year. (I can almost always get a monitor and external keyboard at the office, so it would be a rare day that I was actually stuck with the 1280×800 screen.)
I'm just your average full stack JS dev and I'm not doing any interesting project in my free time besides personal website stuff. Fortunately this means I can do literally everything on the Steam Deck (besides hosting obviously[1]).
What kind of development do you do? In theory, it's possible for a lot of roles. If you can get your environment working smoothly on a distro that Distrobox supports then you should be able to work on it.
I'd love to see someone rock up to the office with a Steam Deck, plug it in, and just start working. That's quite the image.
[1] The Steam Deck has a kind of A/B boot. By default it loads into Gaming mode and the other is Desktop mode. In Gaming mode, most apps and services aren't running (as far as I can tell but now I want to check) so I don't think you could ensure a server stays running in the background if you switched back to Gaming mode. On the other hand, you could live totally in Desktop mode and game from there, only losing the nice Gaming mode GUI.
I do regular web dev (whatever that means lol), but I also do a little bit of that "full build takes 45 minutes... if it doesn't fail because you only have 32GB RAM" dev.
But for that, any laptop sucks, so I've been using suitcase-sized desktops for .. well basically forever. But then in recent years it got so easy to develop on a laptop, but have everything running on a remote machine. I mean there's GitPod and GitHub Codespaces, and before that there were... uh, some web-based IDEs that didn't really work...
But then there came VS Code Remote so like as long as your laptop/[cyber|steam]deck can run VS Code and maybe some browsers, you're good to go!
So I mean OH FUCK IT WHY AM I STILL EVEN TALKING... WHOOOO!!! ORDERED
So if I'm getting this right, the Steam Deck is shaping up to be less of a gaming console and more of a portable DevOps station with a gaming side gig. Guess we're approaching the era where one can fill out an expense report for the boss and sau "I bought this gaming console for development" with a straight face.
Loving the trend, though. Between Distrobox and Docker, containers seem to be the inescapable "Matryoshka dolls" of the tech world.
But all jokes aside, the flexibility this provides is impressive. If you told me a few years ago that I'd be able to run a full Ubuntu environment on a handheld gaming device, I would've raised an eyebrow
No, the Steam Deck is a gaming console. It just isn't deliberately locked out and the fact that it's a computer underneath is left there for you to use if you want.
If you want a portable DevOps station, you want a cheap laptop. You don't want to use the default Steam Deck keyboard for much more than entering a login name or something. A Steam Deck with a keyboard plugged into it is much closer to a desktop setup than anything I'd call portable.
But portability is the only question. It's still a full computer. It just isn't a very convenient one for anything other than games.
I personally do use it a lot like a Nintendo Switch, though. You can easily have a desktop-like setup at home behind a dock, and then pop it out and carry it off portably. It's not quite as slick as a Switch but it works. But, again, this is a desktop setup with the Deck standing in as the computer, not a portable setup.
Close but I'd say it's more like a handheld console with a Chromebook attached.
Steam Deck apps (mostly) have to come from a Flatpak repo to install correctly but Flathub (the default repo and therefore defacto app store on the Steam Deck) has lots of the common apps for daily use, even if they are largely unofficial/unsupported versions. So for 95% of people, it's definitely usable as a laptop/desktop replacement, but if you want to develop or want stuff outside the Flatpak repos, it's a bit of a hassle.
Not the person you replied to but the Steam Deck is definitely a capable dev machine. I wouldn't work on the screen itself but it can handle most day-to-day dev workloads unless you're trying to run 10+ containers running heavy JVM apps on it.
Not the person you're replying to but I've been using the .appimage builds (they're not official) and use Remote SSH on my deck. Works a treat and doesn't need a lot of resources.
Have you seen Rog Ally? It was recently released so it has newer and better hardware than Steam Deck. Unfortunately it runs Windows 11 but I'm pretty sure you can install Linux, or even Nobara Linux if you want to game on it like Steam Deck.
It has a Ryzen Z1 Extreme CPU (Zen 4), RDNA3 graphics, 512Gb storage, 16Gb RAM and 1080P 7" screen, so I think it should be good enough for web development, at least anything that doesn't need more than 16Gb RAM and a beefier CPU, but if you need that sometimes you can go cloud when you need it.
Should include project name in title (distrobox). This is really a game changer for immutable distros. I use Fedora Kinoite and basically everything I use is in an Arch distrobox or flatpak. Best part is, you can just throw a box in the trash and create a new one with only stuff you need. Distrobox-assemble will simplify it further.
I personally prefer building custom images for these distroboxes, where I set up entire toolchains etc inside. So then my OS is immutable, but also all the build tools and whatnot can be rebuilt using a simple podman build command.
Generally only really desktop-ish stuff stays on the host machine (e.g. i3, but also polybar and dmenu), but the rest goes into these distroboxes.
And yeah, like you, I basically live in Arch despite running Fedora. My terminal opens directly into the Arch container, and I’m even installing more and more GUI apps in there, since they are so easy to export to my host launcher.
What is it that you like about running Arch within Fedora, vs. just running Arch (or any other alternatives you have tried)?
I run an Arch VM on Windows; I started out setting up Arch in the VM while experimenting with booting into Arch raw (it's installed on a dedicated, physical disk), but I became distracted and never perfected the raw boot setup, so I just use it as a VM, which I tolerate. The idea of Distrobox intrigues me but I'm not imaginative enough to see how it would help me, so I'm keen to hear your thoughts.
Edit: ah I got to the part of your repo where you mention the below, and I'm watching your video (https://youtu.be/7-FPAWjROos). Makes sense.
>Also, I've never gotten really to know Alpine, the problem with running distros like this bare metal on my PC is that there's a whole bunch of hardware quirks and all sorts of little enablement things that more generalized distros tend to get right.
Oh, first off, I'm not Jorge, sorry, I just forked his repo. haha. But yeah, watch all his videos to get an idea of what's cool about this.
Basically, I use Fedora as an "immutable" base system, then install all my userland apps in an Arch container. It's just a really clean way to run things. My base install never really changes much, and tracks upstream Fedora. Then, if I want to do unsupported things, like install Python packages from Pip and Pacman at the same time, I can, knowing that if I get a conflict, I can just blow it all away and start over without even logging out.
Thanks for the shout out! I haven't seen people talk about some of the other features so I'll mention a few for the others:
At first you do it manually like keeping an ubuntu LTS box around for when I need to do that kind of stuff. Then over time you get annoyed that you have to maintain it and while you've removed the host-maintenance from your life it does feel like you've just shifted the problem to the right and multiplied it every time you make a new box.
And since all this stuff is just docker containers you can just pick your distro, pick your list of packages, and then let git and the automation deal with it, you'll always have your dev environment. Assemble was the last missing piece, I'm looking forward to duct taping all of this together!
https://github.com/ublue-os/boxkit is the "kit" if anyone wants to help out, when you fork it it'll bring the github actions with it, so you can set up builds of your boxes and they'll always be up to date. It's based on alpine but that part can be swapped out no problem.
And for those of you who think this is just too far, `distrobox upgrade` can be useful when you have way too many pets.
Not the OP but one nice thing about Arch is the AUR. Practically everything you could want per-packaged and up-to-date. Distrobox let’s you have this killer Arch advantage on whatever base distro you want. Maybe you love Debian but find the outdated packeges an issue ( fixed ). Perhaps you love Apline but cannot afford to fight with Musl compat ( fixed ).
I love the idea of Chimera Linux and would love to daily drive it. However, package availability is going to be a constant drag. Oh, and it uses Musl as well. Both these problems go away running Distrobox / Arch on top. I could keep the base system clean and simple while having a dev environment that is frictionless and full featured ).
the description is also a fancy wrapper around the "docker" or "podman" words that I've found really hard to explain to people.
("docker is sort of like a vm but more like chroot, and it has a dockerfile that is sort of like a recipe, and a filesystem that is sort of like version control, but..." bleh)
Love it! I've been evangelizing Distrobox in my lab. We do robotics and often have to interface with machines running outdated distros or outdated software. Distrobox has made it trivial to spin up containers running arbitrary versions of whatever we need, while keeping our host machines up to date. In fact, today I'm running hardware demos where I'm controlling an arm by dispatching commands through an ancient version of ROS that I set up with Distrobox.
I've been using this on top of both Ububtu and Fedora Silver blue, to run a Fedora toolbox, works nicely.
There is also a host-exec script that allows to spawn commands outside the container while inside. E.g. it is not possible to run 'podman' nested, but with host-exec can still run containers while inside distrobox (distrobox isn't used for isolation, but for the ability to run a mutable OS of your choice).
There are a small number of programs, usually those that need root (such as 'cpupower') which also need to be run "outside".
Apologies... my info was a couple of months out of date. It used to be based on Distrobox but they announced a few months ago that they were building a replacement using podman, so now it seems they're only using Distrobox for a couple of things.
Love distrobox. Use it on my daily driver. If you are running an Ubuntu LTS / Debian stable / PopOS as your main operating system (because you want stability), but want to run bleeding-edge gui applications in debian testing (or even unstable) in an isolated container, you can. Running GUI applications in Linux containers is usually non-trivial to set-up, but distrobox makes it painless. Install with apt, export to the host operating system with 'distrobox-export --app blah'.
It's pretty much the same from the outside; the difference is how the containers are built and managed. Flatpak uses OSTree with custom build scripts, while distrobox uses Dockerfiles and more standard packaging.
Interesting. I always used LXD. It supported many distros too. You can quickly spin up an LXD container that matches the desired cloud instance type. I can create EC2-like t2.micro instance on local Ubuntu/Debian and see how my app would behave on a cloud instance locally on my workstation. LXD also supports GUI apps and NVIDIA GPU acceleration. I will test this one.
The difference here is, your home directory is tightly integrated. This is something most (all) all virtualization solutions try to avoid.
With support for running GUI applications, this becomes a viable solution for running apps from other distros, running an app as root when you aren't,
and being able to install apps into a system that is immutable.
It is also a lot really really fast to enter that session. (It uses podman or docker rather than lxc like with LXD)
LXD is a faster tool that offers various configurations, such as allowing an app to run as root even when you're not, and mounting host directories inside containers like Docker/Podman. LXD is also unprivileged by default and uses the same Linux kernel features as other tools. We have different tools available for end users, and I prefer running Docker inside LXD for development purposes because it keeps my $HOME clean. Additionally, tasks like Nvidia GPU (such as ffmpeg, or AI) can also be run inside LXD, providing extra security on my dev box while keeping $HOME clean where you may need to use the `curl ... | sudo bash` syntax when downloading random stuff from the Internet.
The last time I tried it (a few years ago) you needed to either run `lxc` as root or be a member of the `lxd` group which is equivalent to having root privileges. At that time the ability to launch and enter container instances as an unprivileged user (without a root backdoor like the docker or lxd group) was one of Podman's advantages. Have things changed since then?
LXD uses unprivileged containers (user namespace) with the setup done by the root user. All containers run in unprivileged mode by default. However, specific config that only a privileged user can do (mount disks/partitions, setup network devices, allocate more complex mappings for the user namespace etc.) on LXD using the root user or LXD group. Even rootless Podman needs root access in many cases. For example, to open port < 1024, mount EFS/NFS inside; in other edge cases, you can't use rootless Podman. These are Linux kernel limitations last I checked and are sometimes caused by various distros applying other security patches to their kernels too.
LXD supports (all of these have pros and cons, and you must choose one of the type that solves your problem):
1. Privileged containers.
2. Unprivileged containers as an unprivileged user.
3. Unprivileged containers as root.
One frustrating issue is that many developers and IT professionals are reluctant to use Podman due to certain unique situations and edge cases. Docker is more commonly used and tested, making it the preferred option despite Podman's beneficial features.
> The difference here is, your home directory is tightly integrated.
lxd supports this too, as well as configuration profiles and a default configuration profile. So the only difference is in default configuration and perhaps ease of configuration.
> The difference here is, your home directory is tightly integrated. This is something most (all) all virtualization solutions try to avoid.
This isn't really true - almost any virtualization or container solution will do this, in the case of containers it's typically just a local volume mapping. Of course the default is typically an isolated execution, that's one of the key tenets of containers or virtualization, but it's usually minimum effort to expose whatever local directory you like. I guess its nice this tool cuts out a small step to make the process convenient, but its not a must install for me personally vs my existing container runtime.
Mapping my entire home directory to a volume is a pretty rare use case for me too - i'm far more likely to just map a project directory to a working dir in the container. I don't think I have ever mapped my whole home folder to a container volume in my career, and can't imagine doing so in future either. This is a bunch of nice shell-scripting to do what you could already do with docker/podman a little quicker.
Yes, please see "How To Install LXD on Debian 11 Linux" [0] and search for AWS or GUI examples. FYI, upcoming Debian 12 will install LXD via APT and you no longer need snaps.
For testing i prefer systemd-nspawn containers with mkosi. A neat tool for running your other fav. distro in a terminal. Works like a charm and integrates nicely in your system. Eg. logs and systemd services or CI testing.
FYI, Toolbox mounts your entire home into each instance (and you can't run separate HOMEs for each instance, as not everything adheres to $HOME all too well). This completely ruined the experience for me.
I think this is typically, but not always, what you want. All of my usage of toolbox was using tools installed inside a container to operate on files in my home.
It implements the same concepts introduced by https://github.com/containers/toolbox but in a simplified way using POSIX sh and aiming at broader compatibility.
All the props go to them as they had the great idea to implement this stuff.
If I understand correctly, Distrobox makes it convenient to launch (and destroy) lightweight VMs on demand, while nix shell makes it convenient to drop into a shell with some package installed. The documentation around nix has unfortunately been unapproachable in my experience.
Of course, Flatpaks+Podman will be a learning curve, but I'm eager to try Silverblue+Distrobox on one of my computers.
From what I understand DistroBox creates a container, not a virtual machine. The difference is that containers share the host's resources and kernel, while a VM is completely seperate
Distrobox is awesome! No need to fight with my Ubuntu based distro for new packages anymore. I just install everything in my arch box now and it works nicely.
Stability of Ubuntu with the power of pacman, definitely a great tool!
Does this support a full Ubuntu Desktop? At my job we test a lot of projects for which we require a load of (GUI) apps. Until now I've installed these in a VM and then reset the VM after the project so my host OS doesn't get cluttered.
If Distrobox can give me a full desktop Ubuntu in a container in stead of a VM that would be very welcome.
You are probably not going to run a “full Ubuntu Desktop” though. Is that what you want?
You would run your normal desktop ( from the host distro ). In Distrobox, you would have Ubuntu installed including whatever GUI apps you need. When you run those GUI apps, they appear on your regular desktop.
Yes my idea would be to have a full Ubuntu Desktop that I can use for a project, and then save it on our git. So when my colleagues have to work on this specific project they can just copy the container and dive in.
Of course this would also work with a regular Distrobox container but that requires more terminal action than some colleagues are comfortable with. Plus it's hard to see sometimes when a GUI app is from a container and when it's on your host. It's almost too seamless.
So having a single "window" into a full ubuntu container would be my preferred option.
In the post link, there's a section called "See it in action" with a video, and in there he shows an example of installing gedit into a container and running it.
If you want to actually use multiple distributions at once integrated tightly into each other (like using Ubuntu with AUR packages) I highly recommend https://bedrocklinux.org/. It uses some chroot and symbolic link magic to share files across filesystems.
> Provide a mutable environment on an immutable OS, like Endless OS, Fedora Silverblue, OpenSUSE MicroOS or SteamOS3
> Provide a locally privileged environment for sudoless setups (eg. company-provided laptops, security reasons, etc...)
> To mix and match a stable base system (eg. Debian Stable, Ubuntu LTS, RedHat) with a bleeding-edge environment for development or gaming (eg. Arch, OpenSUSE Tumbleweed or Fedora with latest Mesa)
> Leverage high abundance of curated distro images for docker/podman to manage multiple environments
For every immutable distro I've considered distrobox or smth similar is the main or secondary way of installing stuff. VanillaOS has apx which is a wrapper for podman, BlendOS is basically built on the idea of distroboxes, and uBlue (which I'm using), ships distrobox and recommends it's usage.
IIRC, Toolbox is less buggy and better tested according to some discussions on both Fedora Silverblue's and Toolbox's GitHub issue trackers.
I don't have links on-hand (mobile), but the discussions should be easy to find by searching "distrobox" in the issue page of the respective GitHub repos. I also can't speak to the validity of it since I haven't really had problems with either.
For me the biggest selling point is being able to install things from official or more trustworthy sources than I can otherwise. For example Signal does not show any official way to run the desktop app on Fedora, but I trust the Archlinux community repo so I can just install it on an Arch distrobox environment and add a launcher for it to my bin. This beats the unofficial Flatpak in my opinion.
It's what allowed me to make the jump to NixOS without having to give up much - every userspace program that isn't packaged up or has quirks along with anything gaming related where I consistently want the newest and greatest runs inside an Arch distrobox container. Can highly recommend!
This is an excellent puzzle piece for testing your software in different environments. What I'm looking for in addition to something like Distrobox is away to easily test with older kernel versions. Does anyone know a tool that makes this easy, easier than juggling VM's manually?
This is a good idea. Are there any down sides to using it? I feel like a proper implementation of this could reduce a lot of noise in the development experience. Some part of me wonders if you can brick your box with it or if there are less than obvious performance costs?
Not an expert, but one risk when using this on an immutable OS is that your start to treat the containers like pets, ie that you're going to want to upgrade then to newer versions and have to do all the maintenance chores an immutable OS is supposed to do away with.
The experimental Sandboxed Mode sounds interesting, there should be a dedicated fork focused on sandbox mode replicating QubesOS with containers rather than VMs.
I use LXD. I can spawn any distro I want. I also use GUI apps this way (including video/audio eg firefox). I also use chezmoi for different HOME environments I want to have inside my LXD containers.
How does it handle EOL distros like Debian 7 for which packages are not available anymore ?
I need to compile the most recent version possible of rsync (or one with some specific zip support) for Debian 7 but I can't install the build tools in Debian 7 in docker :/. What I got so far:
$ docker run -it debian/eol:wheezy /bin/dash
# apt-get update
E: Method http has died unexpectedly!
E: Sub-process http received a segmentation fault.
Well, I should have mentioned I already tried that:
$ cat s ; docker run -it --volume ./s:/etc/apt/sources.list:ro debian/eol:wheezy /bin/dash
deb http://archive.debian.org/debian wheezy main
#deb http://archive.debian.org/debian wheezy main contrib
#deb http://archive.debian.org/debian-archive/debian-security/ wheezy updates/main
# apt-get update
E: Method http has died unexpectedly!
E: Sub-process http received a segmentation fault.
Containers have access to your home X11/wayland, audio, usb, can run graphical applications easily. Can be installed and used without root with podman.
You can even setup booting into a container desktop environment from your login screen.
Containers need both namespaces and groups. While created for different purposes, both serve the same purpose within the container world: Giving processes within a container a limited set of actual host capabilities. If cgroups hadn't already existed, we likely would have a namespace that did the same thing; as it is, we had cgroups, so we didn't that namespace.
This similarity is constructed. Namespacing is largely about entry points into kernel data structures, while cgroups are a form of active accounting. They are orthogonal, and the existence of the cgroups namespace (=the intersection of both) illustrates that.
The Steam Deck default OS (Steam OS 3) is a heavily locked down variant of Arch with only a couple of writable directories. With Distrobox, I can run an Ubuntu environment from one of those directories, ensuring that when I install SDKs or tools, they're being installed to a writable area of the OS but require no config to change what they think is intended install location.