GOG plan to look a bit closer at Linux through 2026

The important part is the builds.
Too many of them depend on libraries that are no longer available in modern Linux Distros.
Also i think they should get rid of that weird shellscript installer that has an archive wrapped in a .sh file.
I also like to see one general gog script interpreter shipped by galaxy that executes allt changes after the game updates instead of each game shipping its own temporary copy. Doesn't work well with firewalls on all operation systems.

Quoting: Lofty

Quoting: CaldathrasWhile I've gotten used to their DRM-free script-based Linux installers, I would love it if they moved the Linux offline installers to AppImage, with all of the dependencies incorporated.

eh, appimage isn't really the 'container format' that it seems to have initially been sold as. In many cases there are system dependencies and linked libraries that as per linux will get updated to a point where by the appimage cannot work at all, which then requires a full appimage refresh & update. it is also not sandboxed without firejail.

( anecdote incoming: i thought i was archiving programs originally, turns out 6 months is a long time in software, my favorite appimage was just a grey empt box with a gtk crash handler message.. and this was on linux mint not exact a rolling release.)


Now flatpak .. That is much more inline with a kind of 'bottled' instance of software, it too also needing to remain somewhat in step with the system but it has some other benefits of better system integration & is sandboxed. Plus flathub / flatpak is becoming the de-facto distro agnostic software distribution method so there is consistency of support via popularity.

imo ofc

Strange, I don't think I've ever had that issue happen to an AppImage, unless it was caused by AppImagelauncher being out of date -- then I've had all sorts of problems. In my opinion, if that happens to an AppImage, the packager is not doing their job correctly. By the way, I can testify from first-hand experience that this can happen with flatpak packages as well. Neither packaging system is perfect.

My problem with flatpak is, as I understand it, you basically end up with an installer that is dependent on the flatpak system to install. To my knowledge, you cannot back it up easily (in manner readily accessible to a basic user) and you need to be online to install it. It is not stored on your system but on a server somewhere on the Internet. If that server goes down -- or you no longer have Internet access (for whatever reason) -- you cannot install the game.

Whereas, the whole point behind GOG's offline installers is that they are self-contained and DRM-free offline installers. To me, the AppImage format fits the bill -- with the ability to include all dependencies, if done correctly. Certainly, some maintenance on GOG's part over time will be necessary. And, heck, even the Windows offline installers are sometimes missing dependencies and need updating (although GOG's Preservation Program is improving on that).

Quoting: Caldathras

Quoting: Lofty

Quoting: CaldathrasWhile I've gotten used to their DRM-free script-based Linux installers, I would love it if they moved the Linux offline installers to AppImage, with all of the dependencies incorporated.

eh, appimage isn't really the 'container format' that it seems to have initially been sold as. In many cases there are system dependencies and linked libraries that as per linux will get updated to a point where by the appimage cannot work at all, which then requires a full appimage refresh & update. it is also not sandboxed without firejail.

( anecdote incoming: i thought i was archiving programs originally, turns out 6 months is a long time in software, my favorite appimage was just a grey empt box with a gtk crash handler message.. and this was on linux mint not exact a rolling release.)


Now flatpak .. That is much more inline with a kind of 'bottled' instance of software, it too also needing to remain somewhat in step with the system but it has some other benefits of better system integration & is sandboxed. Plus flathub / flatpak is becoming the de-facto distro agnostic software distribution method so there is consistency of support via popularity.

imo ofc

Strange, I don't think I've ever had that issue happen to an AppImage, unless it was caused by AppImagelauncher being out of date -- then I've had all sorts of problems. In my opinion, if that happens to an AppImage, the packager is not doing their job correctly. By the way, I can testify from first-hand experience that this can happen with flatpak packages as well. Neither packaging system is perfect.

My problem with flatpak is, as I understand it, you basically end up with an installer that is dependent on the flatpak system to install. To my knowledge, you cannot back it up easily (in manner readily accessible to a basic user) and you need to be online to install it. It is not stored on your system but on a server somewhere on the Internet. If that server goes down -- or you no longer have Internet access (for whatever reason) -- you cannot install the game.

Whereas, the whole point behind GOG's offline installers is that they are self-contained and DRM-free offline installers. To me, the AppImage format fits the bill -- with the ability to include all dependencies, if done correctly. Certainly, some maintenance on GOG's part over time will be necessary. And, heck, even the Windows offline installers are sometimes missing dependencies and need updating (although GOG's Preservation Program is improving on that).

All fair points. I think neither are perfect.
Im not an expert but if you take a look at emulation you can see a that pretty much those games are now theoretically playable for all time .. but then again the caveat is that if you try boot an emulator with an out of date flatpak libraries or an appimage that is not built correctly you have the same problem.

A weird solution would be to build a Retro gaming PC that is offline and remains static in it's updates that is able to play all your favorite windows / console retro games. For newer titles a main upto date PC would of course be needed.

There is no perfect solution tbf. But i do prefer the system of flapak and it's easy configuration of permissions + integration with software centers for the latest features.

Last edited by Lofty on 16 Jan 2026 at 6:26 pm UTC

We've heard this before... Only to see GOG.com put minimal effort into Linux. Actions speak louder than words, so I'll believe it when I actually see more enthusiastic action for Linux users.

I'm not obsessed with the GOG.com like seemingly everyone else; but I'd love to see more games natively supporting Linux (there's a heck of a lot of games in my Steam library that support Linux natively, with no Linux package under GOG.com).

Quoting: LoftyThere is no perfect solution tbf. But i do prefer the system of flapak and it's easy configuration of permissions + integration with software centers for the latest features.

Makes sense. We discussed this in the thread about Canonical and their snaps. @sarmad made a great point about that in regards to AppImages.

Quoting: sarmadIf distros adopted AppImages and have it all configured out of the box it would've been as easy to use as flatpaks, but with extra flexibility, which actually is the essence of Linux.

Comment 288267

Right now, flatpaks have the advantage simply because the distros do the work of putting in all the backend support beforehand. They could do the same for AppImages but right now, those of us that prefer them have to put in the backend support ourselves.

Quoting: sarmadOut of the three formats, AppImage provides the most flexibility: you can download an appimage directly, or use a hub. You can use it sandboxed, or not. You can have appimages auto update themselves. You can use it for cli or gui, etc.

Quoting: Caldathras

Quoting: LoftyThere is no perfect solution tbf. But i do prefer the system of flapak and it's easy configuration of permissions + integration with software centers for the latest features.

Makes sense. We discussed this in the thread about Canonical and their snaps. @sarmad made a great point about that in regards to AppImages.

Quoting: sarmadIf distros adopted AppImages and have it all configured out of the box it would've been as easy to use as flatpaks, but with extra flexibility, which actually is the essence of Linux.

Comment 288267

Right now, flatpaks have the advantage simply because the distros do the work of putting in all the backend support beforehand. They could do the same for AppImages but right now, those of us that prefer them have to put in the backend support ourselves.

Quoting: sarmadOut of the three formats, AppImage provides the most flexibility: you can download an appimage directly, or use a hub. You can use it sandboxed, or not. You can have appimages auto update themselves. You can use it for cli or gui, etc.

yes, agree. i was rooting for appimage in the begging, i do occasionally use them. i admit that the convenience of configuration and the tighter system integration is the draw. And
i think the sandboxing would require an appimage software center that you check box 'sandbox' and it automatically firejails the application.. and then there would need to be a flatseal type application either integrated into the appimage sofware center or a separate app or desktop features for managing appimage permissions like KDE now has for Flatpak.

i admit, complacency shouldn't be a reason for me. But im busy and have around 50 flatpaks installed that get updated daily and i can quickly set permissions in any way i want.
ohh and uninstalling flatpaks is no problem usually with menu entries correctly removed.

but i take your point, like for like properly managed there shouldn't be much difference.

Last edited by Lofty on 18 Jan 2026 at 6:47 pm UTC

Quoting: Cyba.CowboyI'm not obsessed with the GOG.com like seemingly everyone else; but I'd love to see more games natively supporting Linux (there's a heck of a lot of games in my Steam library that support Linux natively, with no Linux package under GOG.com).

I wouldn't say I'm obsessed with GOG but I do prefer having their offline installers instead of depending on the Steam client. Still, I find myself considering Steam for any game running in Linux natively just because the Linux packages tend to be more up-to-date and better supported (what with the Linux runtimes and all).

Yet, I am not sure this is entirely GOG's fault. Oftentimes, it seems like the developer is slower to update their Linux packages on GOG than they are on Steam. It would be lovely if GOG could find a way to copy the Linux runtimes idea and make them work with their offline installers. A guy can dream...

Quoting: LoftyI think the sandboxing would require an appimage software center that you check box 'sandbox' and it automatically firejails the application.

I'd have to check but I think that AM / AppMan (AppImage Package Manager) can do this. It is CLI rather than GUI, however. Perhaps @Bestia can verify.

Quoting: BestiaI'm using AM

(Just to catch @Bestia's attention.)

Quoting: Caldathras

Quoting: LoftyI think the sandboxing would require an appimage software center that you check box 'sandbox' and it automatically firejails the application.

I'd have to check but I think that AM / AppMan (AppImage Package Manager) can do this. It is CLI rather than GUI, however. Perhaps @Bestia can verify.

Quoting: BestiaI'm using AM

(Just to catch @Bestia's attention.)

i suppose some distros could ship this out of the box and integrate that into the system. But at this point i think Flatpak has the mind share. A GUI is kind of essential i think for mass adoption.

Thanks for the software suggestion.

Last edited by Lofty on 18 Jan 2026 at 7:03 pm UTC

Quoting: CaldathrasYet, I am not sure this is entirely GOG's fault. Oftentimes, it seems like the developer is slower to update their Linux packages on GOG than they are on Steam.

It's still GOG's fault. Other platforms got to use the Galaxy SDK to handle uploads and updates; Linux builds they had to use manual FTP and wait for it to be approved on GOG's side. They improved the process somewhat after a number of years, but it's still not as good publishing Linux builds as for other platforms.

Steam just has the same build and update pipeline for all platforms.

Quoting: CatKiller

Quoting: CaldathrasYet, I am not sure this is entirely GOG's fault. Oftentimes, it seems like the developer is slower to update their Linux packages on GOG than they are on Steam.

It's still GOG's fault. Other platforms got to use the Galaxy SDK to handle uploads and updates; Linux builds they had to use manual FTP and wait for it to be approved on GOG's side. They improved the process somewhat after a number of years, but it's still not as good publishing Linux builds as for other platforms.

Steam just has the same build and update pipeline for all platforms.

You would know better than I would. I see your point...