Docker, Distrobox, Toybox, systemd-nspawn, chroot.

Technically those all rely on the same kernel namespace features, just different ways to use it.

That's also what Flatpaks and Snaps do. If you only care about package bloat, an AppImage would do too but it's not a sandbox like Flatpak.

IIRC that's the whole point of flatpak, snap and appimage

Docker can probably do it too, distrobox puts a useful wrapper on that

Nix does that kind of, nix packages aren't isolated in that they can't access resources on your system but all dependencies are stored in the nix store, hashed and isolated from eachother, and wiped when you collect garbage

Snap turns your system into a slug at boot time, makes it take forever to shut down as it unmounts fifty memory file systems, scatters files all over the place turning a neat organized system into a pile of shit. I primary run Ubuntu, but I excise snap from it as one of the first orders of business.

Yes

That's called containerization

Go with one of the ready to use systems. Flatpak, Snap, AppImage. Snap is largely Ubuntu Ecosystem, Flatpak is independent. AppImage is an option if you do not need/want a Sandbox.

Stay away from Docker and LXC for this use case (graphical applications), they are much more work to get going.

Distrobox

One way or another, if you want to run an application you are gonna need its dependencies (the key is the name)... they may be bundled into an appimage or come as part of flatpak ruintime, or be confined inside a container, or live in the nix store, but they will "bloat" your system anyway.

Learn how to cleanup your system (ie. uninstall all packages that are not needed by others that have been requested explicitly) and live a happy life. Only bother with other solutions if the software (or version) you need isn't available for your distro.

You can use appimages, more importantly if you make a directory next to the appimage with the name of the appimage + .home the appimage will also set that as its $HOME that way you can also keep the configuration files of the app separated from the host OS.

You can also sandbox appimages with aisap.

There is always firejail which is very "even your mom can use it" in terms of usage.

e.g install it, type cd / && sudo firecfg, then your password and thats it.

Both strange and not, tbh. On one hand, I understand the sentiment; on the other hand, installing more software with its own dependencies to isolate electron's dependencies, and potentially installing twice those libs both electron and something else on your system depend on seems counterproductive (leaving the security benefits of containerization/sandboxing out of the question here, tho).

Why not Docker?

Distrobox is probably what you’re looking for.

It depends on your usecase. We need more detail regarding what application (gui/cui/open source/proprietary/custom) you are trying to use

• Check if the application you want to use exists as snap/flatpak/appimage.
• If it exists, install the application as per their standard operating mechansim
• Once used, just remove them. Your original system libs are untouched

If the application doesn't exist in those platforms, it's a different story. You might need to use distrobox or docker. Don't use nix because it's overkill for what you want to do.

Look into Incus (formerly LXC) containers or the various i'm gonna replace traditional packaging formats like AppImage, FlatPak and what not.

I'm thinking of using VM but I'm hoping to find a better solution

Yea, I have a Manjaro box also, which is based up on Arch with some ugliness added to it, and yes, I have installed and run Arch before so I am familiar, only problem I've run into is every time I go to do an update one or more apps won't compile and I end up having to remove 35 programs and re-installing to fix. There are a lot of things to like about it though, particularly having packages that are just tar files makes them very easy to extract / modify / create. But not a great system if you just need to get things done.