This is a terrible idea, IMO.

I have several issues with this:

1) with bundled this way packages it is impossible to use mods or fan translations or... basically do anything with game resources;
2) sometimes libraries provided with a package simply refuse to work (I'm on Fedora). I have to delete those *.so libraries to force the game to work with system ones instead (this is particulary true for libSDL2.so and its 'family');
3) as was mentioned before, unpacking everytime you want to use an app has a big impact on launch time. It is tolerable for portable apps but for desktop it has absolutely no excuses;
4) one does not need to install a game: it is an entertainment application for a short time only, not a system-wide utility for mundane use. And besides, the process known as installation stems from the dreaded MS DOS where a game needed to determine hardware and system environment (disk paths, IRQs etc.) before it could be run. Later under Windows a game needed to write some nefarious information (like activation time for shareware games) and user preferences into the Registry. This is not the case under Linux, so the process of installation is reduced only to '*.desktop' links creation. Thus all these debates regarding DEB VS. RPM are completely irrelevant (it is not that the game resolves some dependancies).

1. You can crack open AppImages, so I don't see how they stop mods from being installed.
2.Like I said before, you can open appimages to add/remove files.
3. It's an extra second or two. I don't really see this as a big deal for games in particular.
4.Not sure what the point here is... You do not "install" appimages; you juse run them from whatever folder you put them in.

I do not want to crack anything. Nor should I. All I want is an easy straightforward way to access files. Let's not complicate things without the need, OK?

See above.

I have rather slow (but quiet) WD "Green" disk. I'm sure, in my case it will be more than 1 second.

The point is: let's not fix what is not broken. Current Mojo "installation" method is simple and universal across all OS distributions enough.

And one another thing: how to distribute updates? To force redownload 10+ GiB of data every time? Sure, there are utilites such as xdelta, but honestly, have you used it before? It easier to teach a monkey to play grand piano that to explain a newbie how to apply xdelta patches. Oh, wait! AppImage *has* update capabilities. In the command line...

Overall, AppImage is not meant to be used on a stationary hard drive. It simply does not provide any benefits. And, IMHO, currently GOG should have other priorities (*cough*... Galaxy *cough*) than reimplementing package distribution methods.

"Crack" may have not been the right word, but opening an appimage is not harder than an archive file. Mojo installers try to replicate the 'Windows' way of installing software on Linux. That might not be "broken", but it's still not a good thing.
As for Galaxy, it could also make use of AppImages (and Flatpaks/Snaps) and even update them with the utilites you mentioned, for the user.

Dolphin opens appimages as though they were archive files. I dunno about other file managers, But you can also mount them like an .iso and add files that way.

Games sold on GOG already come packed with their own libs (in most cases), so there wouldn't be much of a file size difference most of the time.

No thanks. Already installed though DNF and I have no idea if appimage has the proper means to hook into the various systems as to keep a program properly updated. And even the current installer isn't perfect, as I found out with Little Inferno requiring some i686 deps. (Resolved, thankfully.) I know that one can use the ldd command in order to check and see what libraries/so files are required. I wonder if GOG can/has implemented such a thing?

As for fired shots, I like having new features in a timely matter, rather than 9 months later. If I wanted to test a buggy alpha, I'd go ahead and run Rawhide.

I care about using standard unix tools, not distribution or DE specific linux-only hacks. With what? Last I looked, fuseiso only implements read support. And again, I would prefer to work with standard unix tools and not some terrible fuse hacks.

Mounting a huge file is not going to work around the fact that editing a huge file will suck. And there are other problems, like support for legacy filesystems that do not support these huge files. GOG currently breaks them down for you, so you can still move your installer on to a FAT32 usb stick.

I repeat: I do not see a single benefit to using a system like this. I only see plenty of downsides compared to what we're using now.

Again, most of the games you get here also have libs bundled with them. So where are you getting that an AppImage version will be all that much bigger?

Also:

>Linux only
>Muh unix

Are you trying to run games for GNU/Linux on BSD?

I didn't say that. But if I have to repack everything into that single iso that contains everything, it's a huge file. As it is, I can deal with all the little files installed on my filesystem of choice.

Should I be able to run these modified AppImage applications without repacking the entire thing into a huge iso? Because right now I cannot. It does not work. If the purpose of this format is to make it difficult for me, it has succeeded. And what if I were? But what I do with my files should not be your concern.

Also there's a reason why installers are compressed. Game data files shouldn't have a layer of compression on them, however. Either the AppImage is uncompressed (it's gonna be needlessly large for distribution) or decompressing gigabytes of data is going to be a major performance burden.

well, ok then. I'd rather have quicker startup times than a bit more convenience :)

and the argument wrt making modding a pain in the ass is certainly true as well.

that's why I wrote 'most' :p

Except you can update an appimage. Granted, you have to use the CLI at this point, but I see no reason why Galaxy couldn't have that functionality built into it, since all the tools are F/OSS.

Seems more people than I thought are bothered by the extra secound or two it takes for AppImages to start. That being the case, I'm open to extending the topic to Flatpak and Snap, neither of which have this problem. Though, both require systemd, which I felt would still be an even bigger issue for some.

You're still triyng to hoist tools on me for no good reason. Why can't I just work with my old tools that have worked fine for decades? Forget that extra second or two. We don't know what linuxvangog tested.

Here are a couple facts: If appimage decompresses the whole image at startup, it is absolutely not suitable for games.

Why? Well, where you store the decompressed version? On the disk? IO is still comparatively slow. Decompressing and writing a 10-gigabyte on the disk game *will* take more than a couple seconds even on a fast SSD.

The other alternative is to decompress it into RAM. Thus RAM reqiurements for the games will absolutely skyrocket, for no good reason. And I still have a hard time believing you could read and decompress 10 gigabytes of data even with a reasonably fast SSD.

There is the possibility of decompressing only the data that is accessed, when it is accessed. But there is another problem with compression; the industry has been for long headed into streaming asssets. If we're going towards the system John Carmack envisioned, we'd mmap assets into GPU-accessible memory, then let the GPU generate page faults, which then result in automatically loading the relevant page of the asset directly from the disk. That is the simplest and likely the fastest way to stream assets into a game, *and* it will reduce memory pressure as the VM subsystem can page out unused data automatically. This works best when the assets are stored on disk in the same format the GPU uses for rendering; a layer of compression will get in the way. It's technically possible to have the page fault handler decompress data for you (and indeed fuse appears to make it possible even with userspace fault handlers), but it's quite nasty, eliminates the most direct DMA path from disk to GPU, and will tax the CPU on a game that might already be stressing the CPU hard enough.

This is all a non-issue for small desktop applications. I don't think AppImage designers ever thought about games.

Well, since the topic has been extended to include Flatpak and Snaps, what is your opinion there? Neither one of these has this issues you bring up with AppImage.

Documentation is too sparse and I cannot be arsed to read the source right now but it looks nasty and doesn't seem to solve any problem I have. But again it does seem to introduce the problem that AppImage has, namely that now I need more tools and steps to tweak the files. Compressed and read-only, it seems to have exactly the same problems that AppImage has.

All three are introducing problems for me and not solving one I have. Apparently they could solve one problem for you, namely having to run an installer before playing a game. Is that such a major problem?

Whatever GOG is doing right now is fine. So the installer look windows-like and isn't sexy (and GOG uses it to shove the EULA at you, which is convenient for them and me assuming I really have to see one). Yeah I agree. But it's not a big deal. Either way the data files end up somewhere on your filesystem of choice, stored in a format chosen by the developer, you can easily mess with them using the good old tools, and indeed I can extract these files from the installer on just about any system. Such as a BSD.