Should be doable to put a Rhapsody theme on it... GNUstep is very flexible in this regard. Thanks to Method Swizzling, themes can change things pretty substantially.
We are on it. The whole UI is going to be overhauled a lot. Would you like to help us get things in shape? AppearanceMetrics.h in gershwin-eau-theme is a start.
Is there anything XAR can do that AppImage cannot?
There are very complex Python applications (e.g., Ultimaker Cura) which are packaged in the AppImage format as self-standing single-file executables, including the Python interpreter, libraries, and other resources.
App availability makes or breaks every platform. App developers only release stuff for platforms with a large user base, and "Desktop Linux" as a whole is at a mere 2-3 percent at this point. So I think the new system would need to ensure that whatever energy an app developer invests into developing for this platform could be re-used to have the same app run on regular Linux distributions. This is something that would need to be solved...
Also, a large brand name behind it (not necessarily a commercial company and in no case a Linux distribution company) would probably help adoption.
Yes, I started klik about a decade ago, over time evolved and simplified the concept and renamed it to AppImage. Thanks for calling it a "lone island of sanity in the ocean of bad ideas on the Linux Desktop" ;-)
After having heard that "this is not how Linux works", I was about to give up when Linus Torvalds himself gave me the impression that maybe the idea wasn't entirely insane altogether.
As for what should be done, I don't think that doing the 1.001st distribution will make any significant difference. Building a system on top of the Linux kernel that is intended to be a platform might.
But then, building something entirely from scratch would require resources I clearly don't have. So how about this:
1. Take the most popular distribution as the basis (that would be Debian/Ubuntu probably)
2. Determine a set of "Core OS" functionality that is comparable to what Windows and macOS do out of the box, and decide that this will be shipped by the Core OS
3. Use distribution packages to install that Core OS into a filesystem image
4. Uninstall the package manager (because it is a tool for the maintainers of the Core OS, not meant for users)
5. Guarantee that only new APIs/ABIs will be added to the system, existing ones can be considered stable and will deprecated only after 5 years (or so) prior warning
6. Release the Core OS once a year (Core OS 2018, 2019, ...)
7. Apps come as bundles (e.g., Rox-style AppDirs or AppImages)
8. Maybe call the loader (ld-linux.so) differently to intentionally only run applications specifically crafted for this system (debatable)
9. Guarantee 5 years of support for each yearly release
10. Developers are advised to always develop against the oldest still-supported Core OS (e.g., the 5 year old one); i.e., if we introduce a new API today then developers can assume it is "there" for everyone 5 years from now; or else they must privately bundle it (similar to how Android works)
11. Address the Desktop Linux Platform Issues https://gitlab.com/probono/platformissues in this system
12. Address the Desktop Linux Usability Challenges https://medium.com/@probonopd/make-it-simple-linux-desktop-u... in this system (possibly modify a desktop environment like XFCE to be more like the Mac/NextStep in philosophy - without copying it verbatim)
AnIdiotOnTheNet, I couldn't agree more. Which is why I've started the AppImage project roughly a decade ago. Would you like to join, even if only as an evangelist? Please get in touch with us via GitHub. It's important to spread the word.
There's also this artificial distinction between the uninstalled and the installed form of the same software. Once you have installed it, it is married into a system that makes it very hard to get it out of the running system again and transfer it to another system (unless you kept the debs or hope that they are still online in some repo).
A better system is one in which the archive/installer and the installed instance of a software is one and the same. Such as a Mac .app bundle or an AppImage for Linux.
AnIdiotOnTheNet, did you know the https://gitlab.com/probono/platformissues project? It is describing the Desktop Linux Platform Issues and what should be done to overcome them. I invite you (and everyone else interested in this topic) to contribute.
Systems like the Open Build Service can ease the pain a bit by building for different distributions and versions, but it is a pain nevertheless. Luckily the Open Build Service instance at https://build.opensuse.org/ can also do AppImages, which run on most "Desktop Linux" systems.
What we need is a clear separation between the Core OS a.k.a. base system which should be provided by every "Desktop Linux" distribution, and the rest.
Applications should only use those shared libraries that come with the Core OS a.k.a. base system, and either link statically to or bundle the rest.
Like an iOS application can only consume what iOS provides or bundle any additional dependencies privately.
The result would be a much simpler and more resilient system (at the expense of some storage and memory overhead, which is the lesser evil imho).
I think we need to distinguish between software that is used as a component in a larger system (e.g., the core OS for which is the core business of a distribution), and an application that is not part of the larger system (distribution) but merely runs on top of it. For putting together a distribution (with tightly integrated components) the traditional packaging philosophy is probably very well suited For add-on third-party software that is not an integral part of the distribution but merely wants to run on it, not so much.
An independent software author (e.g., Ultimaker or Prusa) just wants to reach all "Linux" users at once without dealing with different distribution's policies, and without needing to use the same version of e.g., Qt, that happens to be in a given distribution. And as a user of their software, I want their software on my "Linux" system in the same moment Windows and macOS users can have it.
Since an AppImage is just a compressed filesystem, you can also extract its content very similar to a zip file. But you then will miss out on the easy binary delta updates using AppImageUpdate, and have an extra step of unpacking, and will need more storage space.
An AppImage contains everything an app needs to run on most Linux systems. Just download one file, chmod +x, and run. No installation, no root, no unpacking, no repositories to be managed. http://appimage.org
The Google Earth license does not allow to redistribute it, but you can generate your own Google Earth AppImage by running this script on a x86_64 Linux system.
Let @googleearth know if you'd like to see an official AppImage from them.