As part of this year’s objectives, we want to take on something we believe will help improve user’s adaptability to this distribution. As we’ve stated continuously, AppImages in Nitrux is the preferred method to obtain new software and to improve on this aspect, we’ve made a thing™.
Today, we are announcing the NX AppImage Build Hub.
Nitrux AppImage Build Hub
AppImages by Nitrux for Nitrux
What is NX AppImage Build Hub?
Nitrux AppImage Build Hub hosts repositories to build AppImages automated by GitHub Actions. The AppImages provided by Nitrux AppImage Build Hub target specifically Nitrux (see below). We’ll upload these AppImages to AppImageHub.com, where users of Nitrux can download these AppImages using the NX Software Center. The idea is that by automating the builds of these AppImages, we can provide consistent and updated files compared to the AppImages currently hosted on the website and that these AppImages work in Nitrux.
The repositories in this new organization are forked from a project we used prior, AppRepo, a project created by Alex Woroschilow in 2020, which, unfortunately (at the time of writing) seems to be now gone.
The organization currently has 234 repositories, so each repository represents an AppImage.
How will NX AppImage Build Hub work?
During this initial stage, we will complete the transition for the AppImages to be built using GitHub Actions, and we will upload these files using an account specifically for this purpose. Many AppImages are already building successfully using the CI. Then, we will make changes to the NX Software Center so that only these AppImages are shown by default while also maintaining an option to display all the other AppImages currently available on AppImageHub.com in the application’s settings.
Each repository uses a readme, a Makefile, an AppDir directory, and the workflow file for GitHub Actions. The built AppImage is available in the Releases section of the repository. As there’s currently no way of uploading the AppImage to AppImageHub.com once the CI has built it, we must do this step manually. Since the build process will be automated, the AppImages will be updated regularly.
As for QA, we’d test the AppImages before uploading them, ensuring they work on the latest release available of Nitrux, evidently fixing them if they don’t work (unless it’s a real issue from the software itself and not a packaging issue).
Why “AppImages by Nitrux for Nitrux” and not just “AppImages by Nitrux”?
We know and understand (and agree with) that the stated goal of an AppImage is to work on all Linux distributions; however, for our distribution and considering the number of resources we have, i.e., available humans, ensuring that it is the case becomes impractical, especially for the sheer amount of potential applications; it just won’t scale. With that in mind, we decided to focus on our distribution and only our distribution.
As mentioned earlier, we want to provide AppImages for Nitrux. Since what we’ve observed is that regardless of the quantity of AppImages available on AppImageHub.com and thus displayed in the NX Software Center, there’s the possibility that when a user searches for an application, its AppImage is very old and unmaintained. This then causes the user’s perception to shift negatively since it is assumed by the user that we provide these AppImages (which is not the case for the AppImages currently on AppImageHub.com), so this initiative is, in other words, a “countermeasure” to combat that negative perception by taking the matter on our hands and providing the AppImages ourselves, at least these initial 234 applications.
Additionally, there’s the never-ending issue that some people constantly have with AppImages and how “bad” they are because “how can users be asked to download a file from a random(?) website.” By creating this organization, we, i.e., the system distributor, provide the files and upload them ourselves to an account on AppImageHub.com that we control. So, the trust issue should not be a problem anymore.
Lastly, all these repositories are public as a transparency policy, so anyone can see how these AppImages are built and what’s included in the final AppImage.
Why only 234 applications? That’s too little.
Indeed, 234 applications are not nearly enough. To address this concern, we have also decided on a course of action; at a later stage, after successfully transitioning the rest of the repositories to use the CI, we will search for trusted community members to go ahead and create a separate organization mimicking the approach. The main difference will reside in that the AppImages in this new organization, let’s call it “Nitrux Community AppImage Build Hub,” will be uploaded to a separate account where the AppImages are not expected only to target Nitrux.
It would be up to these community members to keep these AppImages updated and test them, too, effectively a user repository of AppImages; technically, all the content on the website is user generated already; the difference is in this case that it’d be users of Nitrux making AppImages that would take into consideration the use case of a distribution that uses AppImages first-hand.
We’d still upload the AppImages manually to this purported community account. The repositories will be public to comply with the transparency policy described above.
Likewise, we’d update the NX Software Center to include an option to display these AppImages and the AppImages we’d provide or display all AppImages, including those already available on AppImageHub.com uploaded, maintained, or created by third parties.
Why not create your own “store” instead of using exclusively AppImageHub.com?
AppImageHub.com is a website that is part of OpenDesktop.org and is owned by Hive01 GmbH. About OpenDesktop.org: “Started in 2001, OpenDesktop.org is one of the largest websites for the Free Software and Content community.”
This website is part of the same network that hosts the KDE Store.
Having mentioned that, as stated earlier, we don’t have the resources, i.e., available humans, to create, host, operate, and maintain a store on our own. Besides that, since we redesigned the application, the NX Software Center has long used AppImageHub.com as the one source to obtain AppImages. Hence, the API (OCS-API) integration already exists; otherwise, we’d need to invest time creating a new API for the application to interact with the purported new website.
We know other websites that don’t host AppImages but rather link to the repository that does, usually hosted on GitHub. Nonetheless, the issue remains the same: displaying those other AppImages in the NX Software Center requires further development that we’d rather spend elsewhere.
Additionally, AppImageHub.com, through its API, provides metadata we can use, like descriptions, ratings, uploaders, tags, screenshots, etc.
The NX Software Center. Image for reference.
If you have questions, check out our section about how to get involved, join our Telegram group or Matrix chat room.