Flatpak

[dragoondorise]

Flatpak

[MightyCreak]

Yuzu devs are talking about Flatpak in their July blog article:
https://yuzu-emu.org/entry/yuzu-progress-report-jul-2022/

First of, they indeed do not recommend using Flatpak in the first place:

While Flatpak is not the recommended way for our users to enjoy their favourite Switch titles on Linux, due to lower performance and some missing desktop integration features, it is a great option for many Linux users who have Flatpak installed by default and want a low-friction way to get access to yuzu. It has been the preferred choice by Steam Deck users since its release. As the reports from users rolled in, the team fixed some notable Flatpak-exclusive regressions this month.

That said, they give an explanation for why these bugs only happen on Flatpak builds:

But why were these issues Flatpak-exclusive, and not found in the regular Linux AppImage builds? Flatpak enables extra checks in the C++ standard library, which are aimed to catch buffer overflow errors before they happen, intending to help with debugging. Unfortunately, if a check fails, it causes yuzu to instantly crash, which makes it more difficult to debug the issue from yuzu’s log files alone.

The "extra checks in the C++ standard library" might explain the performance issue as well, But I might add that I played Metroid Dread in 2K + AA at a steady 60 fps using yuzu installed through Flatpak. Being a game dev myself, I know that some devs (especially the one dedicated in optimizations) will prefer to remove each and every security checks even if it only saves a few nanoseconds (I know... I've been there too).

But these extra checks actually had very good consequences:

byte[] discovered that due to the size of the optimized layout and the unoptimized layout being different, a subspan used in unoptimizing the layout would overflow and cause the check to fail. The fix was simple: just use the optimized size for the converted layer, since it would always be larger.

When decoding buffers which were input from the emulated game, it was possible for a span operation to overflow. Maide fixed this by being more careful about handling the sample buffers when decoding input.

So not one, but two buffer overflows were discovered thanks to these extra C++ checks! To me, this is a very good thing as buffer overflow is the weak point for any hack/virus.

On the other hand, AppImage doesn't have all that: no extra checks, no sandboxing, no easy way to upgrade. To me, this is problematic. I prefer to lose 1 fps if it means more security. And I definitely prefer to be able to upgrade easily.

And finally, I'd say that thanks to Steam Deck, the yuzu devs are receiving more and more reports from flatpak users, so mechanically, they are giving more love to this package format. So hopefully the flatpak situation with yuzu won't be an issue for very long.

[andrew-kennedy]

the Yuzu flatpak has performance issues

Why is this? Is flatpak fundamentally not able to be built using the same libraries as the AppImage? Seems like a much, much friendlier format for SteamOS as it can be updated right in the Discover package manager.

flatpak has the issue with the sandbox where things get different paths and such

This is fundamentally an issue with any sandboxed image, it's one of the consequences of proper sandboxing that you can't just access arbitrary paths I think...Seems like the fact that flatpak paths might be different vs the AppImage locations doesn't necessarily make them worse...

[KP2048]

We are also planning on making a nice electron frontend for emudeck and appimage is more manageable and doesn’t have the sandbox weirdness that flatpak has

[KP2048]

es-de only appimage no flatpak

[KP2048]

same with srm

[dragoonDorise]

Hi, the only app image we use is SRM and that up to the developers of SRM of doing a flatpak, if they go the flatpak way I'll change that on a heartbeat, having to download an app image is kinda cumbersome.

[KP2048]

Es de is an appimage too

[andrew-kennedy]

@dragoonDorise SRM uses a flatpak now! Did you have any pointers on where to start that change? I'd love to work on a PR for it.

[KP2048]

I’m actually the one that made that flatpak.

[KP2048]

The only real change would be to put the preset files under their respective location under ~/.var/app instead of in ~/.config

[KP2048]

And to have it install the flatpak instead of the appimage

[iMonZ]

Can this issue be reopened please?
Since it’s actually pretty important.

[Godsbane]

I'm not sure about this. We need to probably start heading away from Flatpak, considering many are not even official. The RPCS3 guys made it known they won't suppor the flatpak, and the Yuzu flatpak has performance issues. I think we need to start heading towards more appimages. So what's the gain to changing this thing that already works fine?

[KP2048]

Also flatpak has the issue with the sandbox where things get different paths and such

[KP2048]

Also, appimages can be embedded in other appimages. The problem is updating said appimages

[KP2048]

In other words / = / and / != /var/host/

[iMonZ]

We are also planning on making a nice electron frontend for emudeck and appimage is more manageable and doesn’t have the sandbox weirdness that flatpak has

Electron works perfectly fine with flatpaks.
And maybe there is an alternative for Electron.
Especially when the tool isn’t cross platform.
So I would be really open to help making it work on flatpak and avoiding appimages

[KP2048]

That’s not the issue. Appimages don’t have the mounting issue and permissions issue

[iMonZ]

That’s not the issue. Appimages don’t have the mounting issue and permissions issue

If flatpaks are setup properly they don’t have it as well

[KP2048]

I get it. Flatpaks are cool, but they are a pain to maintain and the whole point of a flatpak is to keep that sandbox and the pathing issue is unavoidable without modifying the base app

[iMonZ]

I get it. Flatpaks are cool, but they are a pain to maintain and the whole point of a flatpak is to keep that sandbox and the pathing issue is unavoidable without modifying the base app

It’s actually the opposite.
ONCE set it up.
Then every update is pushed over a build script.
So I don’t see what Problem you have.

[KP2048]

That doesn’t change the pathing issue.

[KP2048]

I had to merge changes into steam rom manager to support where flatpak mounts the host

[KP2048]

It’s like comparing macOS .pkg vs .app

[KP2048]

.app is portable but .pkg is not

[iMonZ]

.app is portable but .pkg is not

But this is not macOS.
And pkgs are totally different than this.
You don’t need to install drivers or background processes.

[KP2048]

appimages are better because they have less overhead and can run completely standalone as long as you have at least glibc

[KP2048]

Flatpaks require you to install them. Appimage is just an elf binary with an embedded filesystem

[KP2048]

That auto extracts to a temp directory that the app can use

[KP2048]

With flatpak you need to have flatpak installed and you have to deal with the fact that flatpaks don’t have discrete version numbers

[KP2048]

appimage you just download file and double click

[KP2048]

Kind of like the 7zip auto extracting executables in windows

[KP2048]

I get that you like flatpaks. They are cool, but their restrictions outweigh their benefits when it comes to our use case

[KP2048]

Appimages are a better choice here. Because they are simpler for the end user because if they need to update either they can update it from the new frontend we are working on, or they can just download the file themselves and put it in the folder

[KP2048]

And the fact that flatpaks cannot access the data of other flatpaks makes it very hard to make things work in a project like this

[iMonZ]

With flatpak you need to have flatpak installed and you have to deal with the fact that flatpaks don’t have discrete version numbers

What do you mean with no version number?
And how should the person update the tool or know when an update is out?
Checking every day manually on GitHub?

[iMonZ]

Kind of like the 7zip auto extracting executables in windows

Yeah but windows is a con not a pro.
That’s why Linux is using package managers and windows is trying to do the same thing with winget.

[iMonZ]

And the fact that flatpaks cannot access the data of other flatpaks makes it very hard to make things work in a project like this

Why do you think they can’t?
They can indeed.

[KP2048]

No. They cannot

[iMonZ]

No. They cannot

If you set the permission they can.

[iMonZ]

It’s not snap

[KP2048]

Even if you tell it that it can access it it still can’t access it

[KP2048]

The ~/.var

[iMonZ]

Even if you tell it that it can access it it still can’t access it

Tried a year ago with one of my projects.
Worked fine for me.
And why do you need to access different flatpaks?

[KP2048]

Accessing roms and bios and crap

[iMonZ]

Accessing roms and bios and crap

Yeah but they’re in a specific folder like documents.

compromis: instead of an AppImages create an script that does the installing and after that create EmuDeck and EmuDeckUpdate

[KP2048]

And appimages don’t need special handling to access host files.

[KP2048]

You don’t need to prepend /var/host to every host path

[Godsbane]

Can we please use discord for chatting instead? At the very least don't double and triple post. Edit your previous post to include more info.

[KP2048]

Sure. @iMonZ whats your discord?

[iMonZ]

Sure. @iMonZ whats your discord?

❡oldgamer#5354

[KP2048]

Are you on the emudeck discord?
dmed you an invite

[KP2048]

Mine is witherking25#1673

[dragoonDorise]

I’ve deleted some posts discussing a possible scenario regarding the future of EmuDeck, since those were only speculations and I don’t want people to be confused about what we will or we won’t do in the future…

Little late for the party but here are my thoughts.

From a user perspective I think flatpaks are the way to go, they are easy to install and the user can updated them just like any other app from discover in a centralized way.

But maybe we should only use official flatpaks and only if they are not abandoned by their developers, we’ve got several people telling us how Yuzu appImage performance is just better, so even when I like flatpak we are probably gonna change Yuzu to the appImage build.

And regarding EmuDeck being a flatpak in the future or staying how it is right now, the jury is still out on that one, we will test all options and just stay with the one that balances ease of use and ease of maintenance.

[iMonZ]

I’ve deleted some posts discussing a possible scenario regarding the future of EmuDeck, since those were only speculations and I don’t want people to be confused about what we will or we won’t do in the future…

Little late for the party but here are my thoughts.

From a user perspective I think flatpaks are the way to go, they are easy to install and the user can updated them just like any other app from discover in a centralized way.

But maybe we should only use official flatpaks and only if they are not abandoned by their developers, we’ve got several people telling us how Yuzu appImage performance is just better, so even when I like flatpak we are probably gonna change Yuzu to the appImage build.

And regarding EmuDeck being a flatpak in the future or staying how it is right now, the jury is still out on that one, we will test all options and just stay with the one that balances ease of use and ease of maintenance.

Maybe it’s a good idea to look why the AppImage is more performant then the Flatpak. I read that on yuzu is that yuzu isn’t really optimized for flatpak which creates this problem.
But yuzu doesn’t even really work on Wayland so yea they don’t really care for Linux.