I made a video on how I use distrobox on my desktop, and over time as more and more people have been discovering the value of a cloud-native desktop it's starting to gain some attention!
Since SteamOS is an image-based OS right of the bat (must be nice to start green field on that one!) the lack of a more flexible user space was apparent right away, so when Luca and Co. made sure that distrobox worked on SteamOS Liam from Gaming on Linux was quick to check it out:
Then TheEvilSkeleton was interviewed by Brodie Robertson, and they talked about distrobox, leading to this next video:
One of the interesting thing I found in the comments were people having a concrete use case for using a toolbox. It's usually one of the "top comments" when people talk about this class of software: They want Arch's AUR but do it in a safe spot. Or they have an old DEB or RPM from a piece of software that doesn't have a good packaging story on Linux so they can bring that stuff with them.
What I'd like to talk to you today is why you would want to not just use distrobox when you need to solve a problem, but just as your native userspace, all the time.
One of the benefits of explicitly separating our OS and user space is that decoupling, they are no longer dependent on each other. So, for me, my default distrobox is my entire userspace.
I am always in a distrobox, I rarely am ever using the host OS when I'm in a terminal. This gives me a few advantages. Namely, every advantage you get when using containers on a server. :D Remember, I can copy, fork, snapshot, backup, share, all of this stuff, since it's all in my container, it's always going to be with me, forever. It's not just for Silverblue, microOS, SteamOS or EndlessOS.
If you are using Silverblue and you need to install php you install it in a toolbox. And if you're on Arch and you do the same thing you'll be better off, and if you're Ubuntu you'll also be better off. Remember that on mutable systems you really can't go back, once that configuration drift starts to kick in it's too late!
Development in cloud has proven that containerizing these workloads is way faster and more efficient for developers ... and if you don't believe any of that cloud mumbo jumbo think of it this way, less stuff to break on host upgrades. Will stuff still break? Of course. It's just way easier to recover from a broken package or upgrade in a container than it is on the host OS.
So it's not just about getting more packages on your host distro. That is a, really, really nice benefit though isn't it? Keeping the core OS clean and small so that we can have keep that well tested, reliable, and maintainable is a necessity for long-term sustainability.
If you stick your dotfiles in git you can bring them with you from then on, easy to back up, share, and modify. And look at how awesome it is to find someone's dotfiles as a start to your own for a given tool. It's just like that, with the added bonus of having an OS container come along for the ride with everything I need in one convenient package. That's just too good to ignore, it's been my default now for over a year and I'm not going back.