Recently opensuse is creating and making its opensuse micro os to aeon desktop which is a reframe version of opensuse atomic desktop which is its old tested micro os for desktop.
This new aeon desktop will be providing distrobox.
I know there was some discussion about this switch but can this be considered now.
2 Likes
I know you framed your question based around what OpenSuse are doing or have done, but this has been something that has been brought up in some conversations and Matthew Miller has mentioned publicly.
From my point of view, I have not been happy with toolbox. The fact that defining your own /home is extremely hard to do is a downside for me when looking at the 2.
I’m one or two of the Github discussions on this very topic very early into the toolbox development/release. So it’s allways been a pain point for me and honestly a set back versus a now superior solution. Mind you i do not use either at the moment, but back then. . . It would have been a nice to have.
What do you mean has changed since this discussion?
Toolbox has since then added various features around using it with multiple distro images that if anything makes switching less relevant than it was a year ago, not more.
i would be happy to use toolbox if it has the export option easy and simple to use and it is already preinstalled on fedora. Many times i see Distrobox throttle 100% CPU usage and toolbox no havent used distrobox or toolbox for 6 dont know is that fixed, but laggyness and 100% single CPU throttle got annoying when using distrobox. basically distrobox is so popular since it has made export apps so easy and simple that is missing from toolbox and if toolbox makes that then we dont need to install distrobox at all
Although, even in Distrobox, programs that use /home/$USER instead of $HOME will bypass your custom $HOME as it’s still bind mounted into the container.
Custom homes were something I wanted to keep my home directory clean and stop multiple containers from naively trying to write to configuration files like my ~/.bashrc and screw things up, but…I don’t know how many programs would do that in good faith. Is this an issue anyone has actually faced? It doesn’t seem like as big a deal to me as I initially thought.
I do find it kind of annoying that I need to manually patch xdg-open in every Toolbox, but it’s no big deal. I started out using Distrobox and find Toolbox harder to use, but Go is probably a saner implementation language than POSIX shell scripts and I haven’t had any weird bugs with it yet like I have with Distrobox.
Too true. Toolbox used to be those shell scripts, it was rewritten in Go since.
This has been a motivating factor for me in sticking with Toolbox in my current Silverblue system.
I haven’t needed a local CLI with a separate /home lately, but when I do, I’m going to create containers with Podman Desktop.
That said, user-configurable /home is something users want, and it couldn’t hurt, so hopefully it is (or will be) on the Toolbox roadmap.
1 Like
What I would expect from the “saner implementation language” would be more features, and popular user requests fulfilled faster. But from what I have observed, it is the opposite, Distrobox leads in this respect. How Distrobox manages that with shell scripts is beyond me, but it is a fact.
Personally, I am not a heavy user of these tools, but due to recurring problems with Toolbox and “can’t fix, won’t fix, you shouldn’t even be asking” type of responses in the Toolbox issue tracker, I have switched to Distrobox and have not looked back.
3 Likes
I don’t think you’re the first one to make that observation.
Can podmansh be used without making it your login shell? Would podmansh provide for a better experience than either toolbox or distrobox? Or use some other podman command syntax? I like the idea of confining the user using containerization techniques in a cloud native way. It looks like podmansh leverages systemd as well.