yuzu the Nintendo Switch Emulator gets an easy Linux installer

Alternatively I wrote this little bash script to update yuzu (early access) if anyone wants it. Requires jq and curl to be installed.

#!/bin/bash -x
OUTDIR=/home/$USER/apps/appimages

ID=$(curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/pineappleEA/pineapple-src/releases/latest | jq '.assets | map(select(.name=="yuzu-x86_64.AppImage"))[].id')
curl -H "Accept: application/octet-stream" -L https://api.github.com/repos/pineappleEA/pineapple-src/releases/assets/$ID -o "$OUTDIR/Yuzu.AppImage"
chmod +x "$OUTDIR/Yuzu.AppImage"


Last edited by dibz on 12 Aug 2022 at 2:19 pm UTC

Alternatively I wrote this little bash script to update yuzu (early access) if anyone wants it. Requires jq and curl to be installed.

#!/bin/bash -x
OUTDIR=/home/$USER/apps/appimages

ID=$(curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/pineappleEA/pineapple-src/releases/latest | jq '.assets | map(select(.name=="yuzu-x86_64.AppImage"))[].id')
curl -H "Accept: application/octet-stream" -L https://api.github.com/repos/pineappleEA/pineapple-src/releases/assets/$ID -o "$OUTDIR/Yuzu.AppImage"
chmod +x "$OUTDIR/Yuzu.AppImage"

This, and I would prefer using the distro package manager, it's easier.
Probably it's because I'm using linux for some years, that I think that using the package manager it's easier than searching on internet for an installer, downloading it, executing it, and follow an assistant.

Alternatively I wrote this little bash script to update yuzu (early access) if anyone wants it. Requires jq and curl to be installed.

#!/bin/bash -x
OUTDIR=/home/$USER/apps/appimages

ID=$(curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/pineappleEA/pineapple-src/releases/latest | jq '.assets | map(select(.name=="yuzu-x86_64.AppImage"))[].id')
curl -H "Accept: application/octet-stream" -L https://api.github.com/repos/pineappleEA/pineapple-src/releases/assets/$ID -o "$OUTDIR/Yuzu.AppImage"
chmod +x "$OUTDIR/Yuzu.AppImage"

This, and I would prefer using the distro package manager, it's easier.
Probably it's because I'm using linux for some years, that I think that using the package manager it's easier than searching on internet for an installer, downloading it, executing it, and follow an assistant.

Agreed, system package manager any day of the week. AppImages, Flatpaks, Snaps, all seem to be the current (unfortunate) hotness and all of them are sub-par compared to native packaging.

This, and I would prefer using the distro package manager, it's easier.
Probably it's because I'm using linux for some years, that I think that using the package manager it's easier than searching on internet for an installer, downloading it, executing it, and follow an assistant.

For awhile now, I have been using the flatpak version of yuzu from flathub so that it would integrate with my GUI package manager and CLI scripts. Appimages are fine (barring some rare/random incompatibles with Fedora), but FOSS has truly spoiled me to expect all of my updates in one place!


Last edited by Numeric on 12 Aug 2022 at 4:24 pm UTC

Can someone fill me in on this? Wasn’t it already easily installable from flathub? Wouldn’t that just complicate things?

Agreed, system package manager any day of the week. AppImages, Flatpaks, Snaps, all seem to be the current (unfortunate) hotness and all of them are sub-par compared to native packaging.

Flatpak IS a package manager, you know. It’s just that it’s a lot more robust than the legacy traditional ones (dnf, apt, pacman, etc).

Agreed, system package manager any day of the week. AppImages, Flatpaks, Snaps, all seem to be the current (unfortunate) hotness and all of them are sub-par compared to native packaging.

Flatpak IS a package manager, you know. It’s just that it’s a lot more robust than the legacy traditional ones (dnf, apt, pacman, etc).

There's a reason I said system/native. Not everyone likes flatpaks or appimages, and some people do. There are pluses and minuses to using something like a flatpak and the same is true for system/native.

Do you really need a GUI updater for AppImages?

Do you really need a GUI updater for AppImages?

AppImages are unfortunately painful to update. There are GUIs and even daemons out there that can do it, but typically the appimage itself has to be built in a way that supports updating. Yuzu actually is built (now) with support for that sort of thing, so no, it doesn't actually need a different way if you have one of those general appimage update tools installed -- they're not by default. Some apps even support this type of updating built-in, which is nice. Duckstation is another one that supports generic updating, but for example, avidemux's appimage does not and you have to download updates manually.

Alternatively I wrote this little bash script to update yuzu (early access) if anyone wants it. Requires jq and curl to be installed.

#!/bin/bash -x
OUTDIR=/home/$USER/apps/appimages

ID=$(curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/pineappleEA/pineapple-src/releases/latest | jq '.assets | map(select(.name=="yuzu-x86_64.AppImage"))[].id')
curl -H "Accept: application/octet-stream" -L https://api.github.com/repos/pineappleEA/pineapple-src/releases/assets/$ID -o "$OUTDIR/Yuzu.AppImage"
chmod +x "$OUTDIR/Yuzu.AppImage"

This, and I would prefer using the distro package manager, it's easier.
Probably it's because I'm using linux for some years, that I think that using the package manager it's easier than searching on internet for an installer, downloading it, executing it, and follow an assistant.

Agreed, system package manager any day of the week. AppImages, Flatpaks, Snaps, all seem to be the current (unfortunate) hotness and all of them are sub-par compared to native packaging.

Yeah. I went through years of fiddling back in the day when there was no option, grinding through dependencies to finally get to the rpm I actually was trying to install. Things finally got to where they Just Work and I can function while just paying attention mainly to very few sources that only require a click, and I have no interest in going back. Nowadays, if it's not in the Mint Software Manager (or on Steam) it's pretty close to might as well not exist, for me.

I don't have a huge problem with Flatpaks in theory--mild ambivalence, but not like hostility. So if some game's Steam package is actually a Flatpak, or my Software Manager installs a Flatpak, OK, cool. But I'm not going to add a new, uncurated software source like Flathub to my software sources that might not play well with my existing stuff, and I'm not going to start messing with maintaining a bunch of separate software with separate downloads and launchers. Don't get me wrong, it's nice they made a launcher, it's a good step, but unless I have a really compelling reason that's still not quite at the stage where I'm going to use a piece of software. Not even because it would be hard to install, I'm sure it's quite easy. It's just clutter to lose track of, a source of conflicting dependencies, I don't want that kind of mess.


Last edited by Purple Library Guy on 12 Aug 2022 at 8:02 pm UTC

Alternatively I wrote this little bash script to update yuzu (early access) if anyone wants it. Requires jq and curl to be installed.

#!/bin/bash -x
OUTDIR=/home/$USER/apps/appimages

ID=$(curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/pineappleEA/pineapple-src/releases/latest | jq '.assets | map(select(.name=="yuzu-x86_64.AppImage"))[].id')
curl -H "Accept: application/octet-stream" -L https://api.github.com/repos/pineappleEA/pineapple-src/releases/assets/$ID -o "$OUTDIR/Yuzu.AppImage"
chmod +x "$OUTDIR/Yuzu.AppImage"

This, and I would prefer using the distro package manager, it's easier.
Probably it's because I'm using linux for some years, that I think that using the package manager it's easier than searching on internet for an installer, downloading it, executing it, and follow an assistant.

Agreed, system package manager any day of the week. AppImages, Flatpaks, Snaps, all seem to be the current (unfortunate) hotness and all of them are sub-par compared to native packaging.

Yeah. I went through years of fiddling back in the day when there was no option, grinding through dependencies to finally get to the rpm I actually was trying to install. Things finally got to where they Just Work and I can function while just paying attention mainly to very few sources that only require a click, and I have no interest in going back. Nowadays, if it's not in the Mint Software Manager (or on Steam) it's pretty close to might as well not exist, for me.

I don't have a huge problem with Flatpaks in theory--mild ambivalence, but not like hostility. So if some game's Steam package is actually a Flatpak, or my Software Manager installs a Flatpak, OK, cool. But I'm not going to add a new, uncurated software source like Flathub to my software sources that might not play well with my existing stuff, and I'm not going to start messing with maintaining a bunch of separate software with separate downloads and launchers. Don't get me wrong, it's nice they made a launcher, it's a good step, but unless I have a really compelling reason that's still not quite at the stage where I'm going to use a piece of software. Not even because it would be hard to install, I'm sure it's quite easy. It's just clutter to lose track of, a source of conflicting dependencies, I don't want that kind of mess.

If you want me to segue into my issue with flatpaks in particular, I mainly just don't like dealing with all the runtimes that inevitably accumulate. Beyond just duplication of dependencies for stuff that might already be on your system, the versions of runtimes accumulate over time. A flatpak will require one or another, stop being updated, and that old one sits around around with, another software will want a slightly newer version of the same, so on and so forth. The idea is really that flatpaks should share and reduce that overhead (just accepting some duplication with the system) by sharing runtimes, but in practice of like the 10 flatpaks I regularly use almost all of them download their own runtime version of the same thing. You can clean up some of it by asking it to remove unused, but that's very hit or miss; it works for some stuff. I just had to remove like 10 different versions of the nvidia drivers that flatpak downloads over time because it never cleans those up automatically, despite older versions being unused. Frankly, the sandboxing is nice but it's also a pain at times. You can work around it when it's an issue, but I rather dislike working around it.


Last edited by dibz on 12 Aug 2022 at 8:10 pm UTC

Alternatively I wrote this little bash script to update yuzu (early access) if anyone wants it. Requires jq and curl to be installed.

#!/bin/bash -x
OUTDIR=/home/$USER/apps/appimages

ID=$(curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/pineappleEA/pineapple-src/releases/latest | jq '.assets | map(select(.name=="yuzu-x86_64.AppImage"))[].id')
curl -H "Accept: application/octet-stream" -L https://api.github.com/repos/pineappleEA/pineapple-src/releases/assets/$ID -o "$OUTDIR/Yuzu.AppImage"
chmod +x "$OUTDIR/Yuzu.AppImage"

This, and I would prefer using the distro package manager, it's easier.
Probably it's because I'm using linux for some years, that I think that using the package manager it's easier than searching on internet for an installer, downloading it, executing it, and follow an assistant.

Agreed, system package manager any day of the week. AppImages, Flatpaks, Snaps, all seem to be the current (unfortunate) hotness and all of them are sub-par compared to native packaging.

Yeah. I went through years of fiddling back in the day when there was no option, grinding through dependencies to finally get to the rpm I actually was trying to install. Things finally got to where they Just Work and I can function while just paying attention mainly to very few sources that only require a click, and I have no interest in going back. Nowadays, if it's not in the Mint Software Manager (or on Steam) it's pretty close to might as well not exist, for me.

I don't have a huge problem with Flatpaks in theory--mild ambivalence, but not like hostility. So if some game's Steam package is actually a Flatpak, or my Software Manager installs a Flatpak, OK, cool. But I'm not going to add a new, uncurated software source like Flathub to my software sources that might not play well with my existing stuff, and I'm not going to start messing with maintaining a bunch of separate software with separate downloads and launchers. Don't get me wrong, it's nice they made a launcher, it's a good step, but unless I have a really compelling reason that's still not quite at the stage where I'm going to use a piece of software. Not even because it would be hard to install, I'm sure it's quite easy. It's just clutter to lose track of, a source of conflicting dependencies, I don't want that kind of mess.

If you want me to segue into my issue with flatpaks in particular, I mainly just don't like dealing with all the runtimes that inevitably accumulate. Beyond just duplication of dependencies for stuff that might already be on your system, the versions of runtimes accumulate over time. A flatpak will require one or another, stop being updated, and that old one sits around around with, another software will want a slightly newer version of the same, so on and so forth. The idea is really that flatpaks should share and reduce that overhead (just accepting some duplication with the system) by sharing runtimes, but in practice of like the 10 flatpaks I regularly use almost all of them download their own runtime version of the same thing. You can clean up some of it by asking it to remove unused, but that's very hit or miss; it works for some stuff. I just had to remove like 10 different versions of the nvidia drivers that flatpak downloads over time because it never cleans those up automatically, despite older versions being unused. Frankly, the sandboxing is nice but it's also a pain at times. You can work around it when it's an issue, but I rather dislike working around it.

So there you go . . . clutter and mess.
Although in the case of a game, with the size of game files a few library dependency duplicates is tiny. As long as it goes away when I hit that Steam uninstall button, I'm not that concerned.


Last edited by Purple Library Guy on 12 Aug 2022 at 11:26 pm UTC

The idea is really that flatpaks should share and reduce that overhead (just accepting some duplication with the system) by sharing runtimes, but in practice of like the 10 flatpaks I regularly use almost all of them download their own runtime version of the same thing. You can clean up some of it by asking it to remove unused, but that's very hit or miss; it works for some stuff. I just had to remove like 10 different versions of the nvidia drivers that flatpak downloads over time because it never cleans those up automatically, despite older versions being unused. Frankly, the sandboxing is nice but it's also a pain at times. You can work around it when it's an issue, but I rather dislike working around it.

That’s actually a bug specific to the nvidia drivers over there. It’s being worked on.

Apps use newer versions of the same runtime automatically with no intervention from the developers. If a runtime is deprecated, then the dev would have to update. But in the case with flathub, it’s much faster because it’s a unified repo so it has the most attention. With legacy dnf and apt repos however, the app gets dropped from the distro because of the deprecated dependency. So flatpak gives you choice whether you want to keep it or not.

Sandboxing related issues will all eventually get resolved as apps adapt xdg portals (whether flatpak or not).

Agreed, system package manager any day of the week. AppImages, Flatpaks, Snaps, all seem to be the current (unfortunate) hotness and all of them are sub-par compared to native packaging.

Flatpak IS a package manager, you know. It’s just that it’s a lot more robust than the legacy traditional ones (dnf, apt, pacman, etc).

Considering that SteamOS on the Deck is still running Arch packages from January and the user shouldn’t touch the core OS, then I’d rather go with Flatpak.

If the Flatpak is being updated by the developer, that is a better way to get packages plus the Flatpak is portable across operating systems.

Ideally, software is packaged for your distributions packagemanager AND flatpak/appimage. That simple. As a SteamDeck owner, I take both over old times .deb/.sh distributions any time, thank you.

The idea is really that flatpaks should share and reduce that overhead (just accepting some duplication with the system) by sharing runtimes, but in practice of like the 10 flatpaks I regularly use almost all of them download their own runtime version of the same thing. You can clean up some of it by asking it to remove unused, but that's very hit or miss; it works for some stuff. I just had to remove like 10 different versions of the nvidia drivers that flatpak downloads over time because it never cleans those up automatically, despite older versions being unused. Frankly, the sandboxing is nice but it's also a pain at times. You can work around it when it's an issue, but I rather dislike working around it.

That’s actually a bug specific to the nvidia drivers over there. It’s being worked on.

Apps use newer versions of the same runtime automatically with no intervention from the developers. If a runtime is deprecated, then the dev would have to update. But in the case with flathub, it’s much faster because it’s a unified repo so it has the most attention. With legacy dnf and apt repos however, the app gets dropped from the distro because of the deprecated dependency. So flatpak gives you choice whether you want to keep it or not.

Sandboxing related issues will all eventually get resolved as apps adapt xdg portals (whether flatpak or not).

Sounds a lot like "pluses and minuses to each" like I said earlier. :)