Our great sponsors
-
AM
An "AUR-inspired" Database of AppImage packages and a CLI to manage/install/update them system-wide! This repo lists 1900+ standalone apps for GNU/Linux. You can extend it with custom repositories, create your own installation scripts and even build AppImages on the fly! "AM" Application Manager: Easy to use like APT and Powerful like PacMan!
-
junest
The lightweight Arch Linux based distro that runs, without root privileges, on top of any other Linux distro.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Arch-Deployer
Discontinued A script to bulk download an Arch Linux package with all its dependencies to be converted in AppImage.
-
ArchImage
Build AppImage packages for all distributions but including Arch Linux packages. Powered by JuNest.
-
arch2appimage
Discontinued This is a python script that downloads Arch Linux packages (Official/Chaotic AUR) and converts to an AppImage executable
-
-
OBS-Studio-appimage
OBS Studio AppImage built on top of JuNest, the lightweight Arch Linux based distro that runs on top of any other Linux distro.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
In conclusion, I feel really confortable with docker/podman/distrobox/junest... but I also like a lot AppImage packages, so I'm trying to merge both. Something I learned all this time I use Linux is that there is no distro, no package format, no software... that can really satisfy my needs. The best hing I can do to solve this situation is to built it by myself (this is my main project, I named it "AM"). I spent two years to create what I like, after a decade as a common Linux user that uses what distro/package mantainers had to give, and this make me feel better. This last point is the main reason because all these distros and software solutions exists in GNU/Linux.
Do you know Junest? This is a project that I like a lot because installs a mini-Arch Linux on every distro with at least the linux kernel 3! I build AppImages based on deb packages normally, and to do so (as Probono always says) I have to use "the older and still supported Ubuntu LTS still supported as a base (due to glibc)".
Hi everybody, I'm the developer of Arch-Deployer and AM Application Manager
So I merged JuNest and AppImages and I've done ArchImage.
I'm a creator of AppImage packages, the basis always used (and recommended) is to create them based on old distributions for compatibility reasons. With this solution I want to try to break that rule. Both my Arch-deployer and the better known arch2appimage failed at this (and were archived as a result).
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.
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.