This is a neat write up, but I’m curious what gaming inside a Distrobox container would be like. For starters, is there any performance impact or potential glitches like screen tearing, and second, could I say, install a more recent mesa package in the container (assuming this is Fedora Silverblue), and have the game use it?
Should work fine, bazzite even has a premade one, try it:
distrobox create --nvidia --image ghcr.io/ublue-os/bazzite-arch --name bazzite-archOut of curiosity what’s the reason to run games in a distrobox container instead of just running them in the host os?
The immediate advantage is that you could get newer mesa in your distrobox but continue to use a stable one in the host so that it doesn’t fuck up your more important work. I switched to using containers or flatpaks for everything on my system a while ago. I have a distrobox for running odd games I get off Itch and stuff like Steam/Bottles is from flatpak. I even run Silverblue now and haven’t had any major issues for about 2 years at this point. Hell I was switching between GNOME 45 Beta and 44 Stable like it was no big deal.
I’m using the proprietary drivers anyway, afaik Mesa still isn’t as performant as Nvidia is it?
That’s a super interesting idea. I will have to give that a shot!
Right now I just use flatpak for all my gaming needs and shared things like browsers, slack, etc.
My issue with flatpaks is that having too many flatpaks becomes a chore to manage. I did not have a fun time with Steam in a flatpak (required some mucking around to get the DPI and cursor size right) and same with Chromium a while back (took me a long time to figure out how to pass on the flags to enable Wayland support). IMO, having a single container (or a container for a particular activity, like gaming) would be a much more cleaner approach, while offering the flexibility akin to a mutable OS (so no weird flatpak quirks to deal with… in theory). This would also make things like backups easier, I could just save my “gaming” container to one tar and not worry about whether I missed any dependencies etc.
That’s pretty much what I do, spin up a container for anything I need to do and everything is within that… once I’ve finished I blow the container away and all the dependencies go with it. Currently use proxmox as a frontend for that although I ran on the command line for ages before switching to a beefier server.
I do the same with docker - nest it in a container so everything is together (and also so it can’t screw around with the host networking). eg. my lemmy container has the lemmy docker and its dependencies together.
Yeah that’s totally fair. It’s definitely far from perfect. Although, I do like that it provides at least some level of isolation.
Doesn’t nix do all of this without containers?
I think so but this method does remove the quite significant barrier of having to figure out nix’s language and quirks, so I’d argue there’s merit to the workflow. Still, you’re trading it for containerization know-how, so not necessarily the best choice.
Yeah it does. I actually use nix as my base OS on one machine. But when I need to work on a project that will never be packaged with nix, and I need all the dependencies, it really becomes impossible to just use nix.
Nix makes an amazing bas OS, however.
I don’t really get the comparison to vagrant. It doesn’t seem like it feels the same role? Can distro box be used to share environments with other developers or used in CI/CD processes?
I use it to share environments with a small team. Just have distrobox specific Docker files and we can all spin up the same distrobox environment locally.
We end up having a different base docker file (e.g. our distrobox one has editors and stuff), but we all share the same project specific docker file. That same project specific file gets used in CI/CD and deployment, but with a minimal base. So all in all, I would say it’s even better than Vagrant because we run the same system in production.
