Enjoy! And do share your feedback, suggestions, and corrections.
In contrast to other bundling systems, AppImage is designed to enable upstream application authors to be in full control over the entire end-user software deployment experience. An AppImage is basically a self-mounting ISO file that contains an application and everything it needs to run which cannot be expected to be part of the target system(s).
So now we have a practical solution for upstream projects to provide binaries for Linux, but the user still has to:
1. Discover new applications
2. Know where to get AppImages from
3. Download them
4. Make them executable, after having checked whether he trusts them
5. Update them
And the application author still has to:
1. Understand the details of the AppImage format (hey, it's really simple, but still...)
2. Get the application to compile on a "not too recent" distribution such as #CentOS 6 for maximum compatibility with "not too recent" target systems
3. Integrate the AppImage builds into a continuous build system
4. Host the AppImages
5. Make the application known to users
6. Provide updates
By building an ecosystem around the AppImage format, many of these tasks could be greatly simplified. However, just with AppImage itself, the ecosystem should be designed in a community-driven, de-central, interoperable way with no central gatekeepers or points-of-failure, or (if that is not possible) the least number possible.
The following components, loosely coupled (in the sense that they may be used, but don't have to) could be useful building blocks of the AppImage ecosystem. For comparison, I will mention the equivalent in the Docker ecosystem, which is more tightly coupled (in the sense that it is more centralistic).
AppImage-aware IDEs, and build tools and services
If build systems like #CMake and IDEs like #Qt +Creator would make it easy to generate AppImages, more application authors might give it a try. I am aware of at least two 3rd-party systems that are working on this, namely
https://github.com/eloquentstore/appimager and https://github.com/electron-webapps/meteor-electron/.
Registry of available AppImages
While AppImages are intended to be built and hosted by the original authors of applications (upstream), it would still be useful to collect information about AppImages in a central database. This database should ideally be crowdsourced, in the sense that the data should be fetched directly from the upstream application authors; ideally directly from the AppImages published by them on the Internet. The data should be made available for use by by software catalog websites and software centers (syndication). It looks like AppStream can be used for this, https://github.com/probonopd/AppImageKit/issues/48.
No, I don't like the fact that this has to be "central" - but hey, the information must come from somewhere. So I will most likely have to set this up on https://github.com/AppImage.
For comparison, https://hub.docker.com/ is a central registry of available Docker images, but as far as I know, the images must be hosted on Docker Hub in order to be listed in the registry.
Software catalog websites
Software catalog websites (such as http://freecode.com/, http://qt-apps.org/, http://kde-apps.org/, etc.) list applications in different categories, with "product detail pages" showing descriptions, screenshots, icons, user comments, star ratings, etc. It would be beneficial if such websites could get information and metadata about available AppImages from a central registry of available AppImages if they don't want to collect the information from their users and/or if they don't want to collect the information from AppImages across the Internet.
For comparison, https://hub.docker.com/ is a catalog website, but as far as I know, there are no APIs for third-party software catalog websites.
Software centers (such as https://wiki.gnome.org/Apps/Software, https://github.com/KDE/discover, etc.) perform similar functions as software catalog websites but are native applications, coming with desktop distributions. In addition, they allow for easy installation/removal/update of applications. Software centers would need to be updated or get a plugin to access the information from the central registry of available AppImages. In addition, they could query AppImages that are already present on the local machine. Software centers could use the information provided to display applications to the user, download them, and update them using zsync-based binary deltas (a sample implementation of which is available in https://github.com/probonopd/AppImageKit/tree/master/AppImageUpdate.AppDir).
AppImage build farms
AppImages need to be built by either taking pre-existing binaries or binary packages and re-packaging them in the AppImage format, or by compiling software specifically for use as an AppImage. While this could be done manually by application authors, the most convenient way is to do this in the cloud as part of a continuous build (CI) system, triggered by changes in the version control system (git mostly these days).
The AppImage build farm would watch a git repository for changes (https://help.github.com/articles/about-webhooks/), and if changes occur, start a build on a build slave, and build an AppImage. This would be very similar to what https://travis-ci.org/ can do for GitHub repositories already today, but with the difference that the AppImage build farm would not have to be limited to GitHub repositories, but could also hook into the CI systems of large projects like KDE, Gnome, etc., and would use e.g., a preconfigured default container to build on that would come with the latest compilers, CMake, etc. by default in order to speed up builds. Different containers could be provided, e.g., a CentOS 6 Docker container already containing recent builds of Qt and KF5 for building KDE applications. By utilizing build systems such as https://github.com/KDE/emerge, existing metadata required for building could be utilized and the builds could be automated as much as possible.
For comparison, https://hub.docker.com/ also acts as a build farm - users can provide a Dockerfile, Docker Hub executes the instructions therein to produce a Docker image.
Embeddable updater library
Not everyone will use software centers provided by the distribution. Hence, it would be beneficial to have a library like https://sparkle-project.org/ that application authors could include in their application, which would perform binary delta updates on using zsync-based binary deltas (could be a simple GUI frontend to the existing https://github.com/probonopd/AppImageKit/tree/master/AppImageUpdate.AppDir backend). Variants could be provided e.g., for #GTK +, #GNOME , #Qt , and #KDE applications.
Wouldn't it be great if AppImages behaved like applications behave on macOS thanks to LaunchServiecs - download an AppImage, it is automatically registered with the systems (menu entries, icons, file associations, etc.). Delete the AppImage, everything is gone. WIth the help of an (optional) daemon and inotify, this should be possible. https://developer.apple.com/library/mac/documentation/Carbon/Conceptual/LaunchServicesConcepts
We need you!
Join the https://github.com/probonopd/AppImageKit project if you would like to help. Join the discussion here, on the GitHub issue tracker, or on https://gitter.im/probonopd/AppImageKit. But first of all, share your thoughts in the comments below!
Kannst du noch weinen?
Bleierne Beulungen mit spiegelglatter Oberfläche, Wogen, keine Wellen, majestätisch, erhaben und die Anmutung bedrohlicher Wirklichkeit in den Wasserresten. Ein Falter treibt im Winde. Er wurde viel zu spät geboren.
Und die Forellen küssen spitzmündig die Oberfläche.
Und stille Wasser sind tief, wie sie sagen.
Und alles ist wirklich,
so schrecklich wirklich.
So musstest du sein, der du noch immer bist.
Sie vergehen, die keiner mehr sieht, reglos.
Sie gingen in Reihen,
in zielloser Benommenheit.
Sie gingen in Reihen und murmelten.
Sie gruben Löcher in die Erde, damit es werde.
denn ich sehe euch fallen, wie die Bäume im Walde.
Sage mir, warum suchst du den Polarstern auf der Südhalbkugel?
- Leo's GartencenterGardener, 2015 - presentI'm especially speeking with flowers ;)
- Microtec BrixenProgrammierer, 2014 - 2015
- GLOBO Industrial SolutionsProgrammierer/ Projektleiter, 2012 - 2015
- Wolf SystemProgrammierer, 2011 - 2012
- Uni WienBioinformatik, present
- Uni WienPhilosophie, present
- Naturwissenschaftliches Realgymnasium Sterzing
LikeThat Giardino - Ricerca - App Android su Google Play
LikeThat Giardino è un’applicazione di ricerca visuale che ti permette di scattare foto per identificare fiori. Usa la tua fotocamera e scop
Lives of Grass: Living Sculptures by Mathilde Roussel | Inspiration Grid...
Inspiration Grid is a daily-updated gallery celebrating creative talent from around the world. Get your daily fix of design, art, illustrati