Indeed it is. In any case that won't ever change for old wine & dosbox titles, or indeed any old titles unless someone's planning a re-release.

I know this is an old thread but I wanted to revive it instead of starting a new one because there are some points I wish to make.

I have just tried using these appimages and I really liked what I saw. These defiantly make using Linux a lot easier. Truth is I still prefer Windows. Not the sort of thing Linux users typicality want to hear, especially in a Linux thread, but it's tough love and something that's got to be said. I think Appimage is step in the right direction and I think GOG should defently consider using them. If I could get driver and system updates also in the form of an appimage then I'd definitely reconsider my thoughts on using Linux. The biggest hurdle for me are repositories, package managers and dependences. I don't like them and I simply don't want to deal with them. the GOG Linux installer is nice but still lacks a lot of dependencies needed for things to work. I've had a lot of trouble getting GOG games to work on 64Bit Ubuntu, but they work fine on 64Bit Mint. An Appimge just might solve this problem.

That's fair enough, but until dependencies are solved to the point where I can just click, install, play; I'll be sticking with Windows for the time being.

1. I did. I installed Linux and used it on and off for about 5 years leaning how the whole thing works. I also learned how to write in bash. I got Linux to work exactly as I wanted it to.
2. When installing software I go to a website download a file, lick it and it just works. Until I can do that in Linux I won’t bat an eye at it.
3. Gentoo stage 3 installation? Not even sure what that is and it sounds complicated.
4. Linux has a the biggest collection of lazy devs. There is so much prognostication in the community it’s why a lot of the time things don’t work. You can’t criticize Window’s handling of dll files when your system doesn’t even work.
5. Mint has other difference, for examples it includes 32bit lib files which is why gog games work on it.
6. There’s also a reason why most people don’t use Linux and probably never will. If you want more people to come to Linux you’re going to have to make it easier to use.

It's the first time I heard of AppImage. If it allows you to install dependent libraries in a more isolated way that allows for easier cleanup (like static library bundling with executables or something like node modules), I'd say hell yeah!

If it's just a convenience thing so that you don't manually install stuff, I think it'd be great for the average user (if I was in the business of delivering Linux desktop apps, I'd definitely take that route), but for me personally, it'd be just ok.

For myself, I'd love to be able to run my games in a contained way that don't force me to install libraries on the global space.

Ideally, I'd run them in the Docker container, but given my experience running Chrome or even a text editor in a container, I think figuring out all the access to give to the container for games to run would probably be a real chore (and is really an expertise in its own right).

If you look around, you'll see that many GOG games bundle their libraries already. You do not need a system-wide install of them. AppImages don't bring anything new to the table on that front.

And to Magmarock -- if something won't run on your distro, it is unlikely that wrapping that same thing in an AppImage would help any more than sticking it in a tar file or iso image.

1. No, you did not. Bash scripting is not how linux works, how linux works you learn from bottom-up distros like Gentoo, Arch, LFS, Slackware, Netinstall version of Debian etc.

2. This claim is close to idiotic. It already does and it already does not use this, because that would lead to situation similar to WinSxS with tons of vulnerabilities.

3. Its not.

4. Sure, I have one game here sold on GOG with a gamebreaking error known and unpatched since 2015.

5. And isn't nesting another architecture is done exactly because proprietary developers are lazy enough to NOT to include 64bit version of the game?!

Speaking of difficulty, its two freaking lines! This difference is absolutely irrelevant!

sudo dpkg --add-architecture i386
sudo apt install libgl1-mesa-dri:i386 libegl1-mesa:i386 libglu1-mesa:i386 libdrm2:i386 libgl1-mesa-glx:i386 libtxc-dxtn0:i386 mesa-vulkan-drivers:i386 libdrm-radeon1:i386 libdrm-amdgpu1:i386 libdrm-intel1:i386 libdrm-nouveau2:i386

6. What? Linux is not for babies, thats for sure. If you want an OS for babies, pick Andoroid. Ads and useless uninstallable bloat included, secure-protected against removal by babies! Isn't it another brilliant example of how perfect proprietary software is?

Like I said, learn Linux or enjoy your hell. This has something to do with OS being designed with prosumer vs consumer in mind.

That's right, the biggest source of grief for most users has been proprietary software that doesn't work with the ecosystem. Go back in time and we find all the complaints about Java, Flash, Nvidia & AMD proprietary drivers, proprietary games and other apps that only come with 32 bit binaries and rely on old unmaintained apis (OSS!), these same binaries linking against old broken .so:s they won't ship along, etc. etc. And then if you try to use them with a newer libc, they crash because there are bugs that won't ever be fixed, unless you're keen to patch the binary. It's been a total crapfest.

That's not to say all the developers working "with" the ecosystem are without fault. The FDO folk and Red Hat (well at least specific employees) are quite effective at pushing excrement down at distros, and too many are all too happy to swallow it and pass it on. Of course, users downstream get to live with the consequences.

This is as true for Linux as much as it is for Windows (at least with software made for a given distro/distro family, and as long as the developer provides a precompiled version).

It does depend on having the required dependencies installed, but that's no different to how it is on Windows; look at how common it is for people to have to track down an installer for DirectX, VC runtimes, .NET, PhysX etc. to fix it - in fact just today we had someone post about this very problem on Windows: https://www.gog.com/forum/general/dragons_dogma edit: and here's another

Getting the dependencies varies, but it's generally much easier/better on Linux than on Windows.

Often you'll find that Windows software includes the redistributables it needs, which is why you end up with hundreds of identical copies of stuff like DirectX installers, and sometimes run into issues with incorrect versions causing problems (such as inexplicable crashes/freezing etc). If not, then you'll need to hunt them down and install them yourself - go to their respective websites (or use Google or so) to search for the download links for the right versions of the redistributables you need, then download and install them separately.

On Linux you simply open the system's software manager/package manager, enter the name of the dependencies you need then select them & click "install". OR, if you install software through the repositories on Linux then the download and installation of all dependencies will be handled automatically.

Varies wildly from project to project as much as it does for any platform. Some projects are better than others.

As long as you pick an appropriate distro Linux is *very* easy to use now.

Have you not run into applications that bundle broken copies of libraries and crash or freeze?

And have you not run into applications that do *not* bundle some library they need, but instead except you to find it from your repos.. only the ABI has changed and the version you need is long gone from the repos and your next step might very well be to google the .so and download a random build from the internet? That might've been compiled with whatever flags, on whatever system, using whatever compiler. You can try to build your own, but that's going to be a whole another hell if it's an old version you need.

It sounds like you've got a long way to go still :-)

This issue is far from "solved" -- I would say Linux and Windows are equally affected, if only because it is not an OS issue. The applications are the problem. Of course libraries breaking their ABI do not help. But sometimes you just have to do it.

Yes. Usually the fix involves removing the offending library/libraries to force it to use the system provided version.
(have also encountered similar on Windows many times over the years)

Yes to this as well, but the solution in those cases was to create a symlink to the newer version of the library that was available in the repositories. Haven't had to compile any myself or obtain them from elsewhere so far though.

I never said it was solved; my response was to Magmarock's assertion that Windows is always as easy as "download - install - run" and it "just works", and that Linux is more complicated.

Right. This usually works. However, sometimes the application will use proprietary libraries that you won't find in your repos. Even if that particular library weren't broken, it might be linked against a broken version of some common library, with a different ABI version than what your system provides. Then removing that broken library won't work because the other library cannot load the version from your repos. That may often work, but it may also fail spectacularly. Or subtly. Libraries are versioned for a reason, and symlinks across major versions are a major hack.

Now if it fails spectacularly, you pretty much have to find the old version. Which is nice, except that some other libraries your application uses might be linked against the new version! Now you're in real trouble because two different (incompatible) versions of the same library need to be loaded simultaneously. Symbols will clash. There's an example of this diamond scheme if you like to read about it, just ignore the optional dependencies between libd1 and libd2: https://blog.habets.se/2012/05/Shared-libraries-diamond-problem.html

Unfortunately I've witnessed this problem in the wild. Right. You may just have to deal with these issues regardless of the OS. That's about the one thing I can compliment consoles for.

Fortunately I've not encountered any situations as bad as those on Linux yet, but I've only been using it for ~4.5 years and most of the software I've been running has been less than 10 years old.

This is more to do with how the consoles are completely closed down (both software and hardware) & centrally controlled.

This was an interesting discussion.

I think king_mosiah makes the best points, however every argument king_mosiah used in favour of appimage applies equally well to Flatpak, but Flatpak has some advantages:

1. There is no decompression stage. Flatpak's are installed: https://blogs.gnome.org/mclasen/2018/08/26/about-flatpak-installations/ This means that big games will start faster and users with slow spinning disks can enjoy decent performance.

2. Flatpak has built-in security sandboxing technology. Does a game need access to my documents? No. Flatpak wont let it. Note: until Wayland is widely deployed, the Sandboxing is useful but not complete.

3. Flatpak handles dependencies far better than appimage via its use of runtimes. It provides a proper, backwards compatible, stable environment that games can depend on no matter which distro they are installed to (providing the distro has full Flatpak support).

4. Flatpak has a 'host data' feature and a runtime 'extensions' feature which allow Flatpak to conserve disk space and integrate very well with the distro. The extensions and host data files can use system wide fonts, media codecs, widget themes, language packs and even OpenGL drivers for the installed GPU. More info here: https://blogs.gnome.org/mclasen/2018/06/13/flatpak-in-detail/

5. Flatpak supports repositories with auto updating. GoG could not only provide standalone .flatpak files but they could create a proper Flatpak repository that would properly integrate with the user's system. You would see your GoG games appear in the software-centre tool you use (if any) and they would be kept up to date automatically (if you want that).

For those who care: Flatpak no longer depends on Systemd (source: https://flatpak.org/faq/ ).