You can sign up to get a daily email of our articles, see the Mailing List page.

yuzu the Nintendo Switch Emulator gets an easy Linux installer

By - | Views: 30,410

Good news for Linux and Steam Deck fans, the yuzu team have worked to bring the installer for the Nintendo Switch Emulator over to Linux properly.

This was a bit of a sore spot, while you could still install it relatively easily having the proper installer just puts another tick in the box for making it that bit simpler for everyone. Why have they done it now though? As they said previously it was mostly Windows users playing with it but over time they've seen "consistent growth in the number of our Linux users" and so it was only natural for them to improve their own support of Linux.

This new installer supports Mainline and Early Access builds for Linux users. With Early Access builds being available for their Patreon supporters.

The work was done by a user going by the handle toastUnlimited. As with any new thing, it might have some issues so be sure to report any you find.

Article taken from GamingOnLinux.com.
22 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
17 comments
Page: «2/2
  Go to:

Quoting: dibz
Quoting: jordicoma
Quoting: dibzAlternatively 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 August 2022 at 8:02 pm UTC
dibz 12 Aug
Quoting: Purple Library Guy
Quoting: dibz
Quoting: jordicoma
Quoting: dibzAlternatively 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 August 2022 at 8:10 pm UTC
Quoting: dibz
Quoting: Purple Library Guy
Quoting: dibz
Quoting: jordicoma
Quoting: dibzAlternatively 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 August 2022 at 11:26 pm UTC
fireplace 12 Aug
Quoting: dibzThe 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).
t3g 13 Aug
Quoting: fireplace
Quoting: dibzAgreed, 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.
const 13 Aug
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.
dibz 15 Aug
Quoting: fireplace
Quoting: dibzThe 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. :)
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.