I’ve read that containers are preferred for development, but they aren’t persistent and it doesn’t seem like files such as /etc/fstab can be accessed through them when running distrobox (I enjoy editing such files using vim).
It’s also a bit annoying having to enter a specific container to run something like btop.
Are you supposed to layer them with rpm-ostree?
Full caveat - not personally into immutable, 90% of the time I’m in Debian or a derivative. 9% arch or derivative. 1% work requirements made me have to use something else.
So I’m less making a rec on method and more commenting on this:
They absolutely can be, thats the point of mounting volumes. I don’t want to do the same thing more than once, so whether I’m playing with something stupid at home or I’m doing something critical at work, I’m going to make a spot for any and all changes I might want to make to use it again elsewhere, without much effort. That could mean mapping a directory to a volume, setting specific variables in my compose/kompose, having a container grab data from elsewhere every time it starts, or whatever, but the parts I want persistent are, the parts I want variable are.
Keeping whether or not containers are the “right” way on an immutable distro aside, what isn’t persistent for you that should be?
I’ve been loving Incus containers for this very use case. Unlike Docker, Incus containers are by default persistent, and are full system containers, not just applications. So when you launch an Incus Debian 13 container for instance, you get a full Debian 13 installation, but at a fraction of the size of even a small traditional VM.
It’s a great happy medium between Ultra-minimal Docker containers designed for single applications, and old-school heavy VMs.
They don’t actually know