AppImage to distribute games
It's better to see Steam Runtime as Appimage, but not games.
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.
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
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.
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....
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
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.
@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.
I love this idea.
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.
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.
Valve doesn't want Steam games to work without the Steam client.
What a pity.
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)
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.
Aeon_of_Sands_-_The_Trail-x86_64.AppImage
Presented in Steam lib.
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.
Please don't. It would be impossible to launch Appimage-packed games in flatpak .
https://github.com/flathub/com.valvesoftware.Steam/issues/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
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.
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:
- 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.
- 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.
- 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.
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.
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.
Let me be informative for you @alandiwix
- 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.
- 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.
- 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.
- 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.
Thanks, @Goddard however all these arguments are actually not relevant for me:
- 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.
- "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.
- 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.
- 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.
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.
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.
@alandiwix
- 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/
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.
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.
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.
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!
You want to run steam games on your lab machine?
Yea, totally worth breaking these games for flatpak users.
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
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.
AppImage does not break Flatpak and I hope the reverse is also true.
I linked the issue above that is the opposite of what you are saying.
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. ;-)
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.
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.
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 (
-GPUparameter) but Blender AppImage let all my PC's to use GPU (if available).
For me, these are enough reasons to prefer AppImage to Flatpak
@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.
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.
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.
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.
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.
I'll add another vote that Steam should allow AppImage builds of games. It provides another useful benefit over steam runtime: You can compile highly optimized versions of libraries that your game depends on. The default for most distros is -O2, but I can easily use -O3 builds of libraries (opengl, etc.) when I build for my AppImage. this results in my benchmarks online showing AppImage outperforming native builds.
You can even do things like build your libraries for a specific cpu target, like zen4 for instance. Right now for a game I'm helping develop, we have a Dockerfile that builds from cachyos image (since they have native mirrors for highly optimized builds, defaulting to -O3), and based on flags passed in will optionally compile to a specific cpu target. So we can easily generate x86_64-v3, x86_64-v4, or zen4/5 targeted builds, which will include vector optimizations that your cpu can utilize, if you have a more modern CPU.
It would be really nice then if steam let us do cpu detection when a user tries to install the game, and then we can download the app image for their target CPU. This allows users of more modern cpus to get a single file, with all libraries and the game itself compiled to take maximum advantage of their hardware.
I don't see this kind of an architecture being possible with the steam runtime alone. Am I missing a way that it can support this?
The default for most distros is -O2, but I can easily use -O3 builds of libraries (opengl, etc.) when I build for my AppImage. this results in my benchmarks online showing AppImage outperforming native builds.
Eden actually does this already with its appimage builds, it offers PGO optimize builds for different cpu arch levels which massively improve the FPS, so the best way to use Eden is with the appimage.
The default for most distros is -O2, but I can easily use -O3 builds of libraries (opengl, etc.) when I build for my AppImage. this results in my benchmarks online showing AppImage outperforming native builds.
Eden actually does this already with its appimage builds, it offers PGO optimize builds for different cpu arch levels which massively improve the FPS, so the best way to use Eden is with the appimage.
Cool! Do you do that through steam somehow? Or a different delivery platform?
Cool! Do you do that through steam somehow? Or a different delivery platform?
eden releases its appimages here
They are made with sharun, so they work anywhere from ubuntu 14.04 to alpine linux.
I'm pretty sure you can already ship a game on Steam as an appimage as well, I know they exist. And by shipping mesa and all of that like eden does you avoid having to use any dependency provided by the sniper runtime.
I am AGAINST allowing AppImage. It would be a regression and vulnerability.
Could games through steam be distributed as AppImages?
Theoretically yes. This REALLY SHOULDN'T be done. If anyone is trying to do so, you should suggest better methods to them than appimage. Optimally as .flatpak but there's other options too, like: just the raw binary itself, aur, or as a .rpm/.deb package so someone else can make it a flatpak.
- No root needed
Incorrect. Appimage depends on a SUID ROOT BINARY - Fuse2. Furthermore Fuse2 is unmaintained. (https://secureblue.dev/faq#appimage)
- No system libraries changed
Technically yes but this means we are now adding bloat.
For dependencies:
We shouldn't use linking to just a general package like some setups do because we don't want breakage risked. We shouldn't package the dependencies with the application because it adds needless bloat. Instead we should link to a specific version as a dependency which may then be reused by all applications with that same version. Like flatpak allows.
- Just one format for all major distributions
Did you mean: Flatpak? Re: Atomic images. SteamOs being atomic itself and thus favoring flatpak.
- Works out of the box, no installation of runtimes needed
See above for why that's a bad idea. As flatpak furthermore if a dependency has a known piece of malware or is in some way compromised it could be blocked more easily. With appimage this would become nigh impossible.
- Optional(!) desktop integration with
appimaged
Re: Atomic images.
We already have better integration and the foundation for a permission system with flatpak. We should be moving towards more security not less.
- Binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
Once more, handled by flatpak already.
- Can GPG2-sign your AppImages (inside the file)
Though only vaguely related: For some interesting reads as this is a bit repetitive: https://gpg.fail/ and https://soatok.blog/tag/pgp/
Once more though, we already cover this with flatpak. https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-build-sign
@thegreatGreenstar a lot of that information is false and outdated.
Incorrect. Appimage depends on a SUID ROOT BINARY
So does flatpak...
In fact a while back flatpak broke on ubuntu because they added limitations to fusermount3:
https://www.phoronix.com/news/Ubuntu-25.10-Broken-Flatpaks
Fuse2. Furthermore Fuse2 is unmaintained. (https://secureblue.dev/faq#appimage)
The appimage runtime hasn't depended on FUSE2 in years
https://github.com/AppImage/type2-runtime
Since the runtime is linked statically, libfuse2 is no longer required on the target system.
We shouldn't package the dependencies with the application because it adds needless bloat. I
Fun fact the reason I became a contributor to appimage is because I was forced to use the steam flatpak for a while when archlinux removed the glibc-eac patch, it was totally broken to the point I could not play BeamNG on my PC because it would run out of memory lol
In the README of the Steam AppImage repo I detailed several fixes of issues that are present in the flatpak.
https://github.com/ivan-hc/Steam-appimage?tab=readme-ov-file#features
Also fusermount has never been a hard dependency to AppImage, you can run them without fusermount by setting APPIMAGE_EXTRACT_AND_RUN=1
However this is not a good idea as it basically doubles the ram usage of the application.
We make our appimages with a different appimage runtime that supports mounting with namespaces instead.
This is one of the many pieces that allowed us to make truly portable appimages that work on any linux system, from ubuntu 14.04 which is +10 years old to NixOS without its appimage wrapper. For more info see this table here
Meanwhile flatpak, gpu-screen-recorder had to downgrade the flatpak runtime it uses due to this issue lol .
Amazing feat by the freedesktop runtime maintainers where drivers get deprecated faster than distros.
This is a very common debate. I had it recently, and a user responded by sending me a link to a developer's video where he contradicted the virtues he attributed to AppImages and praised the supposed virtues of Flatpak. Personally, knowing why certain distributions support Snap or Flatpak, and having experienced real problems with Flatpak's space management, I have completely disabled the Flatpak service in Discover. If there isn't only a Flatpak version of an application, I prefer to use Distrobox rather than Flatpak. To avoid repeating content from other platforms, I'll leave the link to the Reddit post where I already expressed my opinion, which shows that AppImages are just as secure as Flatpaks, but at the cost of performance and resource consumption, which always favor AppImages.
@thegreatGreenstar a lot of that information is false and outdated.
To a degree, yes, however this assumes up-to-date AppImages. As I will repeat later, if security is brought to par sure, if the specification is made that said requirements are met. Said baseline being: If root SUID is still required it must be maintained.
Incorrect. Appimage depends on a SUID ROOT BINARY
So does flatpak...
Yep. The difference being Flatpak's is maintained. This is valid criticism though, permissions should be minimized where possible and there is almost certainly the potential for such with Flatpak.
In fact a while back flatpak broke on ubuntu because they added limitations to
fusermount3:https://www.phoronix.com/news/Ubuntu-25.10-Broken-Flatpaks
Fuse2. Furthermore Fuse2 is unmaintained. (https://secureblue.dev/faq#appimage)
The appimage runtime hasn't depended on FUSE2 in years
https://github.com/AppImage/type2-runtime
Since the runtime is linked statically, libfuse2 is no longer required on the target system.
Interesting. I don't have enough information to determine to what degree this addresses FUSE2 being needed, though if I understand this correctly it's still being used, just provided by the AppImage in which case it would fail to address the issue of running with ROOT SUID still.
> We shouldn't package the dependencies with the application because it adds needless bloat. I [It is the total opposite lmao](https://pkgforge-dev.github.io/Anylinux-AppImages/disk-usage-vs-flatpak.html)
Unsure about the cause of this, though I am confident there is a way this may be fixed. If anything we should have near-parity in size here, so maybe system packages are being used by the AppImage or similar?
Fun fact the reason I became a contributor to appimage is because I was forced to use the steam flatpak for a while when archlinux removed the glibc-eac patch, it was totally broken to the point I could not play BeamNG on my PC because it would run out of memory lol
This reconfirms that there is near certainly an area to improve flatpak, and AppImage does surpass it here. The question being why and how?
In the README of the Steam AppImage repo I detailed several fixes of issues that are present in the flatpak.
https://github.com/ivan-hc/Steam-appimage?tab=readme-ov-file#features
Screensaver issues once more, area for flatpak to improve, we'll put this under updating how flatpak handles permissions which needs work but still succeeds AppImage.
The performance overhead may be needed for security reasons? https://github.com/flatpak/flatpak/issues/4187#issuecomment-1075512546
Though said overhead is undergoing work for optimization here, thus it just needs more work rather than replacement.
Sandboxable with aisap (squashfs version only) with no performance issues either.
Sandboxable doesn't mean sandboxed by default, sandboxed to at least on par with Flatpak which is already not much should be a baseline.
"sudo" is not required, no need enable 32 bit repo, no need to install flatpak or snap, it should even run on musl distros.
Really neat if true, but this is most likely done by just including such in the AppImage itself so... I hope I'm wrong on this and if possible maybe this can be done upstream to benefit EVERYONE?
Regarding the mess, once more this should be done upstream: https://github.com/ValveSoftware/steam-for-linux/issues/1890
Uses a patched bubblewrap that https://github.com/flathub/com.valvesoftware.Steam/issues/770 launching AppImages from Steam.
Once more for AppImage, does it require that security baseline to be met? If so, great.
Will use the nvidia driver from the host instead of downloading one, note that for this to happen you also need the 32bit nvidia driver, otherwise runimage will fallback to download it.
Seems yes we got that usage of host if possible, but does this work against specific version or are we still risking breakage? And fallback to download it is wrong. Your applications like so shouldn't be managing drivers themself... requiring? Sure. But not managing.
Based off if your AppImage version at least is on par with Flatpak in basic sandboxing by default alongside removing SUID binaries with root or least reducing the SUID scope to only namespaces, then sure, that'd be fine. But the current standard Type1 and Type2 AppImage are insecure and thus should be disallowed.
however this assumes up-to-date AppImages. As I will repeat later, if security is brought to par sure, if the specification is made that said requirements are met.
Are you saying that there are appimages that have not updated?
Well to that I respond that there is a ton of flatpaks using EOL runtimes as well.
flatpak is such a meme here, because the flatpak runtimes often have very short lifespans (less than LTS distros), and some like the GNOME runtime are a total joke only having 1 year of support.
IIRC this problem is one reason why fedora wants to make its own flatpaks, because their own flatpak runtimes have longer support periods, but people hated this idea, to the point that OBS Studio threatened to sue them.
This is a general problem with linux, it is very hard to make stable software that is not insanely outdated. Both AppImage and flatpak are just an attempt at fixing this issue.
I don't think this problem will ever be fixed, last I checked flatpak is exploring virtualization of the gpu lmao
We actually did some benchmarks, and the thing performs similar to llvmpipe 💀
Yep. The difference being Flatpak's is maintained.
And AppImage is not???
The performance overhead may be needed for security reasons? https://github.com/flatpak/flatpak/issues/4187#issuecomment-1075512546
The exploit involves making a fake /.flatpak-info to trick portals into giving apps more access.
This is a problem with flatpak since you don't actually need a /.flatpak-info file to a sandbox an application, which I linked already here
I don't like portals at all, this is a problem with flatpak as well
At least with sas I offer the option o remove access to dbus completely, this will break portals but it is the only good way to isolate applications fully. I like to make my sandbox declarative, that is only give access to xyz locations and no more afterwards.
Unsure about the cause of this, though I am confident there is a way this may be fixed. If anything we should have near-parity in size here
Do you know what flatpak runtimes are?
flatpak runtimes are essentially distros, people like to say they are mini distros but lately they have become insanely bloated, installing anything that depends on the GNOME runtime for example will add you 2.5 GiB of bloat. And gnome runtime only has one year of support, so the user will end up with several different versions of the same runtime blowing storage away.
The solution here is to enforce a single runtime, but this would go againts "the spirit" of open source of preventing people from spinning their own flatpak runtime lol
So basically what flatpak is doing right now, is fixing the fragmentation issue of linux by being a system that makes it less of a hassle to deal with, you still have a ton of fragmentation just that instead of having to install different distros you now have to install different flatpak runtimes.
Regarding the mess, once more this should be done upstream: https://github.com/ValveSoftware/steam-for-linux/issues/1890
flatpak doesn't follow the spec as well
Based off your stuff if you could get it all into an official type3 AppImage or whatever, I'd be fine with the Type3. But the current standard type1 and type2 are insecure and thus should be disallowed.
There is no such thing as a type3 appimage, this is something I disagreed with probono a while back, because people think that type2 means FUSE2, it doesn't work like that. You are like the 20th person that I will have to explain this btw:
Interesting. I don't have enough information to determine to what degree this addresses FUSE2 being needed
The current appimage spec uses the type2-runtime, since 2022 the runtime has been static.
By being static the runtime no longer depended on the host having libfuse. (any version of libfuse).
You still need a fusermount binary on your system, the runtime actually checks all the way up to fusermount99 lol This is also a requirement for flatpak.
The difference is that fusermount is a soft dependency in appimage, while it is a hard dependency in flatpak. You can still run appimages without fusermount (or even with FUSE and namespaces fully disabled at the kernel which would make flatpak impossible).
On top of that in 2023 it was updated to link fuse3 statically instead of fuse2.
This has never been clearly communicated to people that the type2-runtime no longer needs libfuse2, basically all you would get is this warning in appimagekit releases, the wiki was never updated to reflect that.
Though I cannot properly address the other points at the moment, curiously flatpak in game mode and appimage get equal performance in some games: https://github.com/flatpak/flatpak/issues/4187#issuecomment-2878365041
As for type 3 AppImage, unfortunate. So with the whole fuse3 setup and no more fuse2, maybe AppImage could be considered if mandating a specific version or higher which is harder to determine but possible.
With runtimes: Yes, this situation sucks. But so long as there is no noticeable slowdown, it doesn't really matter. In terms of gaming, while this would use a little storage it shouldn't be making any noticeable dent per: https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam
We see here that this would impact ~10% of users, the majority outside wouldn't be truly affected however.
Realistically there are only so many runtimes likely to be used and even at 10 games the vast majority of that storage will be going to the games themself which are usually upwards of 80+ GB.
Finally, regarding spec compliance, seems it was eventually reached: https://github.com/flatpak/flatpak.github.io/issues/191#issuecomment-412879458
I'm not against AppImage for the sake of supporting Flatpak, the goal is to determine precisely where Flatpak falls short so we can determine what we need to make a minimum in an AppImage. We should be increasing the baseline minimum as we add new stuff, as Flatpak is becoming more standard - the main and default method used by games like Hytale.
I am still opposed to just allowing ALL AppImage, but for those meeting the minimum AppImage version to require fuse3 and such - I hold no issue against.
Also regarding browsers with Flatpak
you are right, Flatpak fails in this case. https://forum.vivaldi.net/post/669805
TL;DR of the linked is: Flatpak's sandboxing breaks chromium browsers own. Eventually when they work together if ever Flatpak will be fine but this is not yet.
Until today, I hadn't realized the very interesting and accurate comparison regarding the space consumed by Flatpaks, one of the main reasons why I advise against their use to avoid unpleasant surprises.
Thank you for your detailed analysis.
Could games through steam be distributed as AppImages?
This would have, among others, these advantages:
appimaged