AppImage to distribute games

[probonopd]

Could games through steam be distributed as AppImages?

This would have, among others, these advantages:

• Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Just one format for all major distributions
• Works out of the box, no installation of runtimes needed
• Optional(!) desktop integration with appimaged
• Binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can GPG2-sign your AppImages (inside the file)

[Sunderland93]

It's better to see Steam Runtime as Appimage, but not games.

[probonopd]

Can whoever votes this down give a reason please? And yes, it should entirely be doable to distribute the Steam runtime as an AppImage. In fact I have tried but the runtime is so convoluted that I'd need someone from Steam to collaborate on this to get it done.

[Sunderland93]

Can whoever votes this down give a reason please?

Because Steam games depends on Steam as DRM-service. It's not DRM-free games, like in GOG. And Appimage has make no sense.

Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)

It's already works on any distro which running Steam

One app = one file = super simple for users: just download one AppImage file, make it executable, and run

Not needed.

No unpacking or installation necessary

Steam games simply download and ready to work

No root needed

Steam not needs root, all Steam games as well.

Binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate

Not needed, because Steam updates also work

[probonopd]

It's already works on any distro which running Steam

Yes, but only on those. And the Steam client needs to be installed first.

One app = one file = super simple for users: just download one AppImage file, make it executable, and run
Not needed.

...for you. I just like the convenience of being able to copy one single file to a different machine and have it run, without needing to download or install or unpack anything again.

Steam not needs root, all Steam games as well.

Last time I checked, Steam did invoke apt commands during installation which not only clearly needs root, but also changes the libraries in the system.

Because Steam games depends on Steam as DRM-service.

Bummer.

[Sunderland93]

I just like the convenience of being able to copy one single file to a different machine and have it run, without needing to download or install or unpack anything again.

Then use GOG :) Steam client as Appimage is good idea, but Steam games as Appimages....

[jubalh]

It's already works on any distro which running Steam

So I run Steam on openSUSE Tumbleweed. Trying to open Magicka 2 nothing happens. No error window nothing.

So I do:

cd .local/share/Steam/steamapps/common/Magicka 2/engine
./Magicka2_x64       
./Magicka2_x64: /usr/lib64/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found (required by ./Magicka2_x64)

So it needs a different version of openssl that openSUSE ships.
So much for works on any distro which running Steam :(

Having the games as AppImages would make much more sense.
No more dependencies on having the libs at the paths that they are located in in Debian.
No more dependencies on having exactly the same (old) lib installed on the system.

Then use GOG :) Steam client as Appimage is good idea, but Steam games as Appimages....

Exactly the games are the ones not working because of being built against different paths/library versions

[RafaelLinux]

It's already works on any distro which running Steam

So I run Steam on openSUSE Tumbleweed. Trying to open Magicka 2 nothing happens. No error window nothing.

So I do:

cd .local/share/Steam/steamapps/common/Magicka 2/engine
./Magicka2_x64       
./Magicka2_x64: /usr/lib64/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found (required by ./Magicka2_x64)

So it needs a different version of openssl that openSUSE ships.
So much for works on any distro which running Steam :(

Having the games as AppImages would make much more sense.
No more dependencies on having the libs at the paths that they are located in in Debian.
No more dependencies on having exactly the same (old) lib installed on the system.

Then use GOG :) Steam client as Appimage is good idea, but Steam games as Appimages....

Exactly the games are the ones not working because of being built against different paths/library versions

I agree. Exactly the same is happening with Zero-K in OpenSUSE 15 and Steam Play (beta). I can play Zero-K with Lutris (needing previously to install mono-base, that's the truth) but I supposed that Steam will play Zero-K without any user intervention after installing it from Steam platform, but it's doesn't work. After installing it in Steam, I launch Zero-K and ... nothing happens (it seems to begin to launch and nothing happens finally). So, yes, I think AppImages could solve these problems.

[nipsy]

@jubalh You've probably already moved on at this point, but my report in #6014 discusses how to successfully run Magicka 2. Steam already includes most of the essential libraries needed to run a lot of the i386 and x86-64 Linux games.

But if you're going to try to run them directly yourself from the command line, you need to run them via a wrapper script which sets up the environment in which the games run for the dynamic linker to be able to find the libraries installed with the Steam client itself.

Something like this (the fix and how to run it with the Steam versions of these libraries):

ln -s ~/.steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0 ~/.steam/steam/steamapps/common/Magicka\ 2/engine/libssl_conf.so
cd ~/.steam/steam/steamapps/common/Magicka\ 2/engine; ~/.steam/ubuntu12_32/steam-runtime/run.sh ./Magicka2_x64

Adjust your own Steam installation path as necessary in the above obviously.

[Goddard]

I love this idea.

[probonopd]

Check out NotepadPlusPlus-7.7.1-x86_64.AppImage which bundles a 32-bit Windows application and a custom subset of Wine to run it into a single-file 64-bit Linux AppImage:

https://github.com/probonopd/libhookexecv/releases/continuous

Multiarch or 32-bit libraries are not needed on the target systems to run this.

[jvschiavo]

It's already works on any distro which running Steam

Yes, but only on those. And the Steam client needs to be installed first.

I think you already answered yourself. Valve doesn't want Steam games to work without the Steam client.

[probonopd]

Valve doesn't want Steam games to work without the Steam client.

What a pity.

[jvschiavo]

Valve doesn't want Steam games to work without the Steam client.

What a pity.

Maybe you could suggest that idea to GOG. They believe in no-DRM.
For Steam, the best we could get is the Steam client itself in an AppImage (if this is somewhat possible)

[probonopd]

For Steam, the best we could get is the Steam client itself in an AppImage (if this is somewhat possible)

I had once tried it but then given up because it looked like as soon as I modify Steam, it reinstalls itself.

https://github.com/AppImage/AppImageKit/wiki/Bundling-Steam

[thisnickwasfree]

Aeon_of_Sands_-_The_Trail-x86_64.AppImage

Presented in Steam lib.

[igorlogius]

An AppImage version of the steam launcher/client would really be great.
I hope the valve team at least considers it.
Looking at some of the bash scripts used, it think it might make things more maintainable and portable.

[alandiwix]

Please don't. It would be impossible to launch Appimage-packed games in flatpak .
flathub/com.valvesoftware.Steam#770

Yes, AppImages use fuse to mount themselves, so it's not possible to run them in flatpak (fuse requires suid root binary fusermount).
I wonder what was the reason for them to ship AppImage through S

[probonopd]

It would be impossible to launch Appimage-packed games in flatpak

There would be no need for Flatpak in this case at all. Users could just download and run the AppImage. Valve would be in full control of software distribution without having to rely on a third party such as the organization behind Flatpak.

In fact, this is a key design goal of AppImage - to put application/game authors and end users in full control without any middlemen/gatekeepers in between.

[alandiwix]

There would be no need for Flatpak in this case at all.

While there is no need in AppImages already. Flatpak is strictly superior in features:

1. Most AppImages rely on host's glibc and some of them even drop some of the libraries considered "standard" by developers. Flatpak includes everything up from the kernel. The only requirement is to be able to compile the Flatpak and it's opensource dependencies.
2. There's no sandbox mechanism in AppImages and it's impossible to use them without suid binary - that means it's impossible to use it in sandbox tools like bubblewrap.
3. There's no reliable update mechanism in AppImages, while in Flatpak it's just one command to do nice delta update (of course this is neglible in Steam's case, because Steam does delta updates, but it is worth mentioning).

You may use whatever you prefer for your system, but this change would break Steam in Flatpak that just works for a lot of users.
Some of the games are already packed via AppImage and they do not work for considerable amount of users.

So, if you are a game developer and read this thread - please do not pack your native steam game as AppImage. Use Steam runtime and pack it in a standard way.

[probonopd]

Flatpak is strictly superior in features

No.

it serves a totally different purpose.

With AppImage, one game = one file. Simple!

Most AppImages rely on host's glibc

With AppImage, the author of an AppImage can decide what to put inside it. If the author wants to, the author can put glibc and everything else into the AppImage.

it's impossible to use them without suid binary - that means it's impossible to use it in sandbox tools like bubblewra

No. Wrong. Please don't spread FUD.

There's no reliable update mechanism in AppImages

Again. Wrong. Please don't spread false information.

Next time you want to discredit something, you need to try harder. Because each of your claims can easily be disputed by a quick web search.

[alandiwix]

No.

No. Wrong.

Again. Wrong.

Because each of your claims can easily be disputed by a quick web search.

Not very informative.

I see that you are somehow related to AppImage development, so I'm obviously not going to convince you.

Thankfully, developer mentioned in the issue above is migrating from AppImage to standard Steam runtime. I just left a warning for any other game developer passing by.

One more thing to be considered: Valve also uses bubblewrap for Steam runtime to some degree and as mentioned AppImage doesn't work with it out of the box.

[Goddard]

Let me be informative for you @alandiwix

1. The only thing you might consider superior is the dependency resolution, but this is actually a problem and over-engineering for Flatpaks. It is truly a wasted effort because the space saved is really marginal. Look at the difference for Libreoffice for example compared to a Flatpak. It won't matter. In my last comparison it was only 35MB difference. So far all that extra head ache and complexity you save 35MB. It is pointless venture and a classic example of over engineering in my opinion.
2. I believe this was answer, but you can put whatever you want in the appiamge. Other similar formats exist for Linux and have been used for a long time by Nvidia and other software vendors.
3. firejail is literally an example used for confining or "sandboxing" your application. Honestly in my experience you usually have a bunch of unrelated people putting together Flatpaks and they are usually broken in some way when confined. So it is better for it to be confined when needed, but not by default because if you don't trust the developer then why are you even downloading it? But that is a personal opinion.
4. Appimage has software available to include with the appimage to update, package managers exist, "App Stores". So many options exist. With Appimage you could literally just use wget honestly because wget has a flag to only download new content if it has changed. It literally makes the problem of updating a non-issue.

The best thing about Appimage is the simplicity.

[alandiwix]

Thanks, @Goddard however all these arguments are actually not relevant for me:

1. Space usage grows catastrophically with more games/apps you install, because properly packed (see 2) AppImage provides all its dependencies and these dependencies are duplicated for each AppImage. More so for GUI apps, where you can often cut 90% of size just by deduplicating the framework.
2. "App developer decides what to put in AppImage" is actually a huge flaw, some developer may consider "standard" way too many libs and can be reluctant to add more because of the size increase. The experience between AppImages may vary from "just works" to "totally broken, won't fix" for some distributions. But the worst is that right now to support musl-based distributions you have to pack complete underlying distribution (aside from the kernel) and this clutter will be duplicated in each AppImage (GBs of useless duplicated data). This is simply unacceptable.
3. I don't want to go into comparing firejail to bubblewrap, but to my taste bubblewrap is more elegant and lightweight solution that is easier to use at the same time. Bubblewrap is just around 70KB in size with the only dependencies being libc and libcap and with proper kernel config it's not even suid. I would say this is dramatical decrease in attack surface. You say flatpak is "overengineered", but suggest some custom jury-rigged firejail setup over built-in bubblewrap at the same time. But ok, you can sandbox an AppImage somehow.
4. I see that you see opportunity for windows-like updates as advantage, so let's just say I prefer linux way. I don't want reinvent the wheel for basic operations like verifying/repairing all installations. Using GNU extension to wget to update apps is hilarious, sorry.

And yes, AppImages doesn't work at all for my distribution, and while glibc-based apps can be executed in flatpak/bubblewrap (and "just work" btw), AppImages doesn't even work with that (and extracting them basically negates all few advantages of AppImage).

It seems you are not going to convince me either, let's just end this.

[probonopd]

Space usage grows catastrophically with more games/apps you install, because properly packed (see 2) AppImage provides all its dependencies and these dependencies are duplicated for each AppImage.

This is due to the design principle that an AppImage must have no dependencies other than the base system (distribution). However, space is cheap these days. So the actual overhead for bundling everything is in many cases way less than people think. Because unlike with Flatpak runtimes, an AppImage needs to bundle only the parts that the particular game/application actually needs. And if all distributions would finally agree (maybe nudged by the Linux Foundation) on a common base system (Linux Standards Base), then not everything would have to be bundled.

Proof? On a blank system, install LibreOffice via Flatpak. Measure all network traffix with ifconfig. Then repeat the same exercise with AppImage. I guarantee you will be very surprised by the results.

"App developer decides what to put in AppImage" is actually a huge flaw

Not if the resulting AppImage is tested on a well-known mainstream distribution, like the oldest still-supported Ubuntu LTS. Then as long as all distributions are binary compatible to that (as they should) things will work properly. The AppImage format encourages all distributions to be binary compatible to the oldest still-supported Ubuntu LTS in order for things to work properly, whereas Flatpak just works around the issue by shipping private copies of everything. Talk about wasteful!

But the worst is that right now to support musl-based distributions you have to pack complete underlying distribution

No. You would have to bundle only the parts that the application actually uses, which is actually way less than "a complete underlying distribution (aside from the kernel)". I am stating this from experience, not from speculation. Not every file in a distribution is actually used by a particular application. Flatpak totally negates this fact. For example, it requires you to download a full Qt even if a particular Qt applciation uses only 10% of it.

I don't want to go into comparing firejail to bubblewrap

Me neither, because I am neither an expert in nor believer in sandboxes. But nothing prevents the Bubblewrap developers to add AppImage support, like the Firejail developers did.

I see that you see opportunity for windows-like updates as advantage

AppImages are designed to be "one app/one game = one file".
This allows for very flexible handling without the need for package managers or any kind of special tools. You can "manage" them by drag-and-drop in the file manager. I am not aware of any other solution that beats this simplicity, apart from Mac .dmg files which come close.

But the main point is that with AppImage, there is no gatekeeper in between the software author and the end user. No Red Hat, no Flathub, no nothing. It allows software authors and end users to be in full control and not to have to worry about random policies of middlemen.

[alandiwix]

And if all distributions would finally agree (maybe nudged by the Linux Foundation) on a common base system (Linux Standards Base), then not everything would have to be bundled.

Or we could just use Flatpak that works right now even on distributions not supported by AppImage.

But whatever, just don't suggest breaking Steam games for everyone who uses flatpaked Steam by pushing your product.

We want Steam and games to just work (on even most "exotic" distributions) like it does right now with Flatpak.

Few care for ideological stuff like "one app/one game = one file" and imaginable "simplicity" of your solution ("make all distributions agree on Linux Standards Base so my stuff will work"), sorry. I bet that the stuff you would include in LSB is way more "overengineered" than Flatpak will ever be.

[Goddard]

@alandiwix

1. I just told you I literally tested it and it didn't grow catastrophically. It was quite the opposite actually. It was marginal.

Here is the entire source size uncompiled of glibc. This is the deb package size by the way.
Package: glibc-source
Version: 2.34-0ubuntu3
Priority: optional
Section: universe/devel
Source: glibc
Origin: Ubuntu
Maintainer: Ubuntu Developers [email protected]
Original-Maintainer: GNU Libc Maintainers [email protected]
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 25.4 MB
Recommends: xz-utils
Breaks: cross-toolchain-base (<< 45~), cross-toolchain-base-mipsen (<< 10), cross-toolchain-base-ports (<< 37~)
Homepage: https://www.gnu.org/software/libc/libc.html
Original-Vcs-Browser: https://salsa.debian.org/glibc-team/glibc
Original-Vcs-Git: https://salsa.debian.org/glibc-team/glibc.git
Download-Size: 19.7 MB
APT-Sources: http://us.archive.ubuntu.com/ubuntu impish/universe amd64 Packages
Description: GNU C Library: sources
This package contains the sources and patches which are needed to
build glibc.

Here is glibc's ftp http://ftp.gnu.org/gnu/glibc/

[probonopd]

Or we could just use Flatpak that works right now even on distributions not supported by AppImage.

Except that it doesn't

• Work e.g., on Ubuntu without having to install Flatpak first (something that is unlikely to change as long as Red Hat dominates Flatpak)
• Work on immutable systems like Live ISOs
• Allow for "one app/one game = one file" simplicity
• Work without gatekeeers that are standing in between the software author and the end user
• Let you store downloaded games/applications in an easy way and archive/store them easily
• ...

This thread is about AppImage. Please don't abuse it to advertise alternative ways of distributing software.

[probonopd]

I just told you I literally tested it and it didn't grow catastrophically. It was quite the opposite actually. It was marginal.

Yes, glibc is under 20 MB. Which is not that bad imho. Actually, not all files in the glibc package are actually required by all games/applications. Most require only about half of it. I have tested this. So, roughly 10 MB overhead. Not bad at all. The payload game/application could even be built with something like musl libc, further shrinking the footprint.

[alandiwix]

Work e.g., on Ubuntu without having to install Flatpak first (something that is unlikely to change as long as Red Hat dominates Flatpak)

sudo apt install flatpak - problem doesn't exist

Work on immutable systems like Live ISOs

Live ISOs use overlay tmpfs these days, and I use flatpak on readonly root (except for some dirs in /var) - problem doesn't exist

Allow for "one app/one game = one file" simplicity

Ideological thing, solution for a problem that doesn't exist

Work without gatekeeers that are standing in between the software author and the end user

You can spawn your own flatpak remote or push your software to flathub quite easily - problem doesn't exist

Let you store downloaded games/applications in an easy way and archive/store them easily

Why would I? I can checkout any ostree commit in flatpak. You could also just archive /var/lib/flatpak.

[probonopd]

sudo apt install flatpak - problem doesn't exist

Not possible if you are using, e.g., a lab machine where you are not the administrator.

With AppImage, you just download one file, set the executable bit, and run it. No administrator permissions needed!

[alandiwix]

You want to run steam games on your lab machine?
Yea, totally worth breaking these games for flatpak users.

[probonopd]

I want to run anything on any machine without system administrators being involved.

And this idea is very popular, even on Windows:
https://portableapps.com/about/what_is_a_portable_app

[alandiwix]

Well, you could do that even without AppImage or by building AppImage for your stuff yourself.

But even if you can't do that for some reason, as I said, this usecase is not worth breaking Steam games for Flatpak users.

[probonopd]

AppImage does not break Flatpak and I hope the reverse is also true.

[alandiwix]

I linked the issue above that is the opposite of what you are saying.

[probonopd]

if Flatpak breaks FUSE, that's Flatpak's fault then, not AppImage's.
The proper solution is to get rid of Flatpak, not complain about AppImage. ;-)

[alandiwix]

Ok, now we can conclude: your product provides no advantage over Flatpak aside from "make Steam games work on my Ubuntu lab pc" and "one app = one file" ideology (that is not an advantage actually). While Flatpak provides plenty of advantages (sandbox, deduplication, more distributions supported, etc.) with no real disadvantages aside from "it's not installed on Ubuntu by default".

At first, I thought you were just unaware of problems your suggestion here would bring to so many people. But you seem to be aware and totally okay with that, pushing job of fixing stuff to other people instead.

Your "proper solution" doesn't work in real world, sorry. And I hope people will take into account this kind of AppImage developers' mentality: "I suggest to break working setups for people for no real advantage and make other developers fix their software to be compatible with my crap".

There's a better solution: never use AppImages in Steam (maybe even do not use them at all) because they provide no real advantage over standard Steam runtime and other existing software.

[probonopd]

But you seem to be aware and totally okay with that, pushing job of fixing stuff to other people instead.

We should get the mess that "Desktop Linux" is as a platform fixed (by subtly forcing distributions to get their act together and be compatible to each other, at least on a certain minimal common denominator) rather than working around their incompatibilities (by not using the distribution at all, like Flatpak does). I guess this is the difference in our philosophies, which we can agree to disagree on.

[RafaelLinux]

From the point of view of a Linux desktop user with years of experience, I must say that I personally prefer AppImage files, for several reasons:

• They allow me to have a "portable" version of my applications on a USB stick or in a network folder shared between different computers, and all those applications will be available as soon as a Linux computer has access to that folder.

• The versions compiled by the distribution itself (and I guess Flatpak too) often do not include compilation parameters that can only be activated when the binary is created. For example: Blender. The official Blender version for my distro does NOT include the possibility to render using GPU (-GPU parameter) but Blender AppImage let all my PC's to use GPU (if available).

For me, these are enough reasons to prefer AppImage to Flatpak

[mgord9518]

@alandiwix I have a working project that sandboxes AppImages using bubble wrap (aisap) which packages itself, along with bubble wrap into it's own AppImage -- SUID free, so I'm not really sure what you mean by impossible. AppImages can also be sandboxed through Firejail.

[Samueru-sama]

There's a better solution: never use AppImages in Steam (maybe even do not use them at all) because they provide no real advantage over standard Steam runtime and other existing software.

Flatpak itself refuses to comply with the xdg-base-dirs specs by hardcoding ~/.var, something they actually said wont fix and steam is also another program that hasn't fix that issue and at this point I don't think they will either.

appimages have the option to create a portable home for them, if steam came as an appimage I could move all the crap they place in my homedir easily.

[RafaelLinux]

Having it as AppImage only let you to locate where is that file. You must create symbolic links to another folder outside your home partition. That's how I do at least. Then, when you install Steam games, it will placed in another partition.

[Samueru-sama]

Having it as AppImage only let you to locate where is that file. You must create symbolic links to another folder outside your home partition. That's how I do at least. Then, when you install Steam games, it will placed in another partition.

That's not issue, the issue is that I want my homedir to be clear of unsorted dotfiles, and just having the symlink doesnt get rid of them.

I do have a hack working, which is using the native package of steam with a fakehomdir using a wrapper script that setups a fakehome for it inside .local.

[Samueru-sama]

We ended up making an AppImage of Steam here

Also includes fixes like the patched EAC Glibc, Zenity-gtk3 (because gtk4 version just flashbangs you lol), recent version of mesa and a patched bubblewrap that allows launching appimages from Steam.

I can finally get rid of the useless top level dotfiles that Steam makes by making the .home dir next to the steam appimage without the wrapper scripts hacks lol.