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.
https://github.com/pkulak/boxkit
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.
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.
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 ).
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.
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.
So the next logical step is to just make it declarative, so it's one of the reasons we made boxkit. Distrobox has an exciting new feature coming out called assemble: https://github.com/89luca89/distrobox/blob/main/docs/usage/d...
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.