junest VS OBS-Studio-appimage

Explore the Junest Git project and follow the installation instructions. Activate the environment with junest setup and enable the running-from-host options.

PS: about JuNest (see https://github.com/fsquillace/junest ) this is a lightweight Arch Linux based distro that runs, without root privileges, on top of any other Linux distro. I also suggest to take a look at it.

About JuNest, all the apps installed using it whave always worked well for me. I've also wrote a script and done a pull request (rejected) for a tool that exports the apps to the launcher (as distrobox-export already do) https://github.com/fsquillace/junest/pull/322

JuNest https://github.com/fsquillace/junest looks very complete and good, though I dislike the approach of having to download or build an image. It would be nice to be able to do stuff like clone my filesystem (already ZFS) and branch an environment off that instantly.

I have already done a PR (see here)to the main repository https://github.com/fsquillace/junest but I still get errors in merging this utility during the automatic github-action's test/check. Any idea?

- I have pacman installed through junest. It works for command line programs, did not test for gui software

Have you tried installing JuNest? It will allow you to download, install, and use Arch's precompiled binaries directly (in addition to making it easy to compile, install, and use AUR packages).

As for the rest, I've been testing stuff with distrobox, junest (which is like distrobox, but for arch guest and without the container), and Conty (a lot like Junest but as a single hyper-compressed executable file). Anything requiring an escalation or wanting actual access to root remains an issue, but for the most part, it works well enough.

OBS Studio https://github.com/ivan-hc/OBS-Studio-appimage from 200 to 167

Visit https://github.com/ivan-hc/ArchImage for more!

In my experience with Flatpak, when upgrading a runtime (from Nvidia) to the next version, used by the same app (WINE), I ended up with two runtimes and not even the "uninstall –unused" option had removed it , I did it manually later (and it's not very intuitive). Also, aside from "du", most disk space measurement tools still identify an inordinate amount of space, and even if you show me that article (which is one of many I've already read about it) this does not changes my experience with this format, because "ostree" is not a very intuitive system even for those who, like me, are used to LSB (Linus Standard Base) standards. I had to intervene on a malfunction of a single app I wouldn't be able to make my changes, while on a regular package it is still possible to do it... and for AppImages it is even more so. I once reported a problem to qBittorrent maintainers on flathub (this), never got a response. On the contrary, movements on the repository have made them (I'm telling you about when qBittorrent was switching from qt5 to qt6), and it was correcting their file and then returning it to the previous version. I don't know how apps work on runtimes, but this attitude (which I've seen in real time) seemed to me to be that of people who didn't even know what they were doing. With AppImage at least I have the security of knowing what's inside. Taking OBS again as an example, in the past whoever built this app in AppImages obtained packages ranging from 70 to 150 MB of space (always compressed), while I use other systems to package my AppImages at most and managed to bring it to 250 MB with deb packages (and it still doesn't work, some environment variables that I didn't include in the AppRun... you can see it here), not to mention the fact that many developer's platforms cut out the workspaces that we used to build on (i.e., for backwards compatibility issues we use usually the oldest Ubuntu LTS release still supported). I'm trying to go differently than the AppImage constructors of the past, and this method looks promising.