Distrobox’s aim is to integrate a container with the host OS’ data, to the extent possible. By default, everything (process, network, filesystem) are shared, and in particular, the home directory is mounted into the container as well. It is not even trying to be “a sandbox,” even when using the --unshare-all option.
I also found out the hard way that Distrobox integrates devices explicitly. If some USB devices are unplugged, the container will not start. This happened because I pulled my laptop away from its normal dock area (with USB hub, keyboard, and fancy mouse) and tried to use a distrobox. Thankfully, I wasn’t fully offline, so I was able to rebuild the container. [Updated 2024-11-28: This danger is persistent. Creating a container without the USB devices connected, then running it later with the devices, will make it fail to start if the devices are unplugged. This ended up being impossible to live with.]
Before it stopped performing properly in Ubuntu Studio 23.10, I used distrobox to build ares and install it into my home directory. This process yielded a ~/.local/share/applications/ares.desktop file, which my host desktop picked up, but which would not actually work from the host. I always needed to be careful to click the “ares (on ares)“ in the menu after exporting, to start it on the ares container.
I have observed that distroboxes must be stopped to be deleted, but then distrobox will want to start them to un-export the apps. Very recent distrobox versions ask whether to start the container and do the un-exporting, but there’s still a base assumption that you wanted the distrobox specifically to export GUI apps from it. It clearly doesn’t track whether any apps are exported, because it always asks, even if none are.
No comments:
Post a Comment