Quoting: EagleDelta

Quoting: dibz

Quote...on more bleeding-edge Linux distributions...

To protect your privacy, external media requires approval to load. Source: pics.me.me
View cookie preferences.
Accept & Show Accept All & Don't show this again   Direct Link

Rarely do I run into issues on "bleeding edge" distributions. It's also important to note that "Bleeding Edge" distributions aren't generally using "Bleeding edge" versions of software. Latest upstream stable versions? yes

Granted, when I think bleeding edge, I think software in beta stage (complete but still testing). There is a HUGE HUGE HUGE problem with certain distributions still using versions of upstream software that the upstream project has made end of life (Python 2.x anyone?)..... which is not a good practice in today's security environment.

Honestly, when I saw the headline with Valve and glibc my very first thought before reading the article was "that's what you get for choosing Arch for newer packages." Which was their stated reason for the switch to Arch in the past. Once I read the article I found out that wasn't the case, and they were just commenting on the situation.

I'll admit my idea of Bleeding Edge may also be an outdated view of what the difference is, which would be a shame if that's the case. Why on earth would people blur that line on purpose? It's silly because the term becomes meaningless if people put it on everything. Bleeding Edge used to mean, essentially, Nightly. Not only would compatibility not be guaranteed between updates, it could completely break.

Personally I still prefer how Debian labels things with stable / testing / unstable. It's clear what it is and isn't, I would consider unstable to be their bleeding edge. I'm not personally advocating using Debian or anything, it's just a good example.

View this comment - View article - View full comments

Quote...on more bleeding-edge Linux distributions...

View this comment - View article - View full comments

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

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

Quoting: MilaniumDo 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.

View this comment - View article - View full comments

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

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.

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

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"

View this comment - View article - View full comments

The game looks a LOT better then the teaser stuff that's been put out so far.

Also, like everyone else, not a big fan of the art style or animation -- mostly the animation that the art style requires, I think. It reminds me of the 2D art you see for Pixar movies sometimes, like Monsters Inc, or the art that gets used for the preschool books related to them.

View this comment - View article - View full comments

Quoting: itscalledrealityThree decent point and clicks for free. I’m not upset but GOG would probably reach more customers if they updated their catalog a bit and gave away more recent games or games from different genres.

To each their own, I thought their giveaways were phenomenal this sale. Not all of them were point and clicks, yesterday was Flashback. About a month ago they gave away Shantae and the Pirate's Curse too.

View this comment - View article - View full comments