probonopd

Exactly. Design, to us, is also how it works. Not just how it looks. The "feel" part in "look and feel".

Gershwin is using the key next to the spacebar (whatever is written on it) as the Command key.

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.

Definitely let's talk. You'll find us on GitHub Discussions and Libera Chat.

This is why we think something inspired by the HIG needs to be reborn as open source.

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)

Who wants to do it?

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.

And almost no one uses them. Or did you get your Photoshop in the Windows Store?

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.

bubblewrap works for sandboxing AppImages:

https://github.com/probonopd/AppImageKit/issues/152

Actually the sandbox used for Flatpak can also be used to run AppImages already now:

https://github.com/probonopd/AppImageKit/issues/152

Depending on the scenario, an app packaged as an AppImage may launch as fast as or sometimes even faster (due to the compression) than an installed app. In most cases, there will not be a noticeable difference for normal desktop applications. Since an AppImage is also a valid ISO, you can loop-mount it and copy its contents wherever you like, and do a comparison.

You shouldn't run "random binaries", but binaries from the original author of the software. E.g., Scribus from https://www.scribus.net/ or Subsurface from https://subsurface-divelog.org/. If you don't trust the original application author, then you should better not run the software at all.

Well, this is what Linus had to say about packaging: "I've seen this firsthand with the other project I've been involved with, which is my divelog application. We make binaries for Windows and OS X. We basically don't make binaries for Linux. Why? Because binaries for Linux desktop applications is a major f*ing pain in the ass. Right. You don't make binaries for Linux. You make binaries for Fedora 19, Fedora 20, maybe there's even like RHEL 5 from ten years ago, you make binaries for debian stable, or actually you don't make binaries for debian stable because debian stable has libraries that are so old that anything that was built in the last century doesn't work. But you might make binaries for debian... whatever the codename is for unstable. And even that is a major pain because (...) debian has those rules that you are supposed to use shared libraries." (August 29, 2014 DebConf Q&A with Linus Torvalds)

Well, the code is on https://github.com and my AppImages are on https://bintray.com/probono/AppImages - once https://github.com/isaacs/github/issues/156 is closed, appimage.org, too, can go https.

Probably just because I haven't had the time to investigate them yet. Can containers be used without the need for root access? Pull requests welcome.

Which is why you want to build on a system that is using an older version of glibc than the systems you want to run your software on. Assuming that glibc does't break backward compatibility, which it really shouldn't (and in practice, rarely ever did). Or use https://github.com/probonopd/AppImageKit/tree/master/LibcWra...

You can use either static or dynamic linking. An AppImage is really just an ISO container wrapping around your binaries.

AppImageUpdate lets you update AppImages in a decentral way using information embedded in the AppImage itself. No central repository is involved. This enables upstream application projects to release AppImages that can be updated easily. Since AppImageKit uses delta updates, the downloads are very small and efficient.

https://github.com/probonopd/AppImageKit/tree/master/AppImag...

Linus Torvalds addresses some core issues in his "DebConf 14: QA with Linus Torvalds" talk starting around 5:40 https://youtu.be/5PmHRSeA2c8?t=5m40s