yuzu the Nintendo Switch Emulator gets an easy Linux installer

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

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).

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.

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.

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. :)