Quoting: CyborgZetaI'm honestly surprised how out of date the Arch base is in SteamOS 3.0.

Given how SteamOS 2.0 went, I can't say I am . . .

View this comment - View article - View full comments

Quoting: canichangemyusernamelaterquestio

Quoting: ExpandingManKind of frustrating: I had tried pretty hard for months to get this game working on Epic (through Heroic and Lutris) but I absolutely could not get it to run. Then it releases on steam and it launches right away. This understandably makes me pretty nervous in general that I won't be able to get non-steam games running, which isn't a great feeling.

Hi, my first post here! Hello y’all!
I registered because I felt the urge to add my 2 cents on this…
While I completely agree why one can be wary of valve’s dominance on this segment of the market (linux gamers), I’d like to add the following thought: every single competitor of valve can start tomorrow with building up their support of Linux in a similar way as valve does. Not a single person or entity prevents them from doing so. They actively choose not to support Linux and by doing this, they leave the entire market segment to valve. Can you blame valve to take up the opportunity?
In my humble opinion, the “fault” (if you can speak of a fault) lies with the competition, i.e. GOG, Epic and all the other stores that don’t support Linux.
It’s valve’s competitors that allow valve to be the dominant actor here.

In other words: Linux gamers are customers waiting to be grabbed/served, you just have to support their platform. If you cede this customers over to your competitor, you have only yourself to blame.

Maybe I’m wrong. What do I know? These are just my thoughts on the subject.
Now convince me that it was a mistake to register on this site. Haha :D

I'm actually fairly down with that position.
Come to that, if Valve's Steam Deck and some other developments make Linux a bigger target, perhaps those others will start to compete for it.

View this comment - View article - View full comments

Gah! My Tolkien!
Well, mind you, I have no particular reason to imagine the Embracer/Extender/Extinguisher Group will do a worse job with Tolkien IP than the Saul Zaentz company.
Anyway, it seems like Middle-earth Enterprises' rights are not as complete as I initially thought. From Wiki:

In November 2012, the Tolkien Estate, trustee and publishers sued Middle-earth Enterprises (in addition to Warner Bros. and New Line Cinema) for infringing Tolkien's copyrights by producing casino and video games using his characters. The original license to Tolkien's works was limited to the right to sell "tangible" products such as "figurines, tableware, stationery items, clothing, and the like", but did not cover "electronic or digital rights, rights in media yet to be devised or other intangibles such as rights in services"

Seems like they have the movie rights, and rights to character names, and merch, but probably not video game rights, basically because video games didn't exist in 1968 when Tolkien sold the rights.

Other limitations on Middle-earth Enterprises' rights (they extend only to The Lord of the Rings and The Hobbit) may partly explain why the big new series from Amazon is taking place during the time period before LoTR takes place, in late Silmarillion territory.

View this comment - View article - View full comments

Quoting: Klaas

Quoting: Purple Library GuyUm, how many of these other thingies are we typically talking about existing at a time?

Run ldd on a binary and count the number of libraries that are referenced.

No. I won't RTFM either.
In any case, would that tell me much about the total system usage?

View this comment - View article - View full comments

Question: There has been talk about how not getting rid of the old version of the function thingie requires these other thingies taking up 16K more memory each. Um, how many of these other thingies are we typically talking about existing at a time? Cuz like, if there's often a billion of them on a desktop system, I can see that being a big problem, but if there's like five, I don't give a damn.

View this comment - View article - View full comments

There's a lot here I'm not qualified to comment on. But one thing I've seen a bit that I think is pretty clearly a misconception:

This is not about Arch, or about Arch's bleeding edge nature.

I don't use Arch and I'm not the kind of guy who wants to run bleeding edge. But if anything, Arch here functioned as a useful coal mine canary. If a new GlibC had contained a bad behaviour that the GlibC people just hadn't caught yet, and they quickly rushed out a bugfix point release that no longer did that, and the only distro that pushed out that first, buggy GlibC without waiting was Arch, then it would be about Arch. But that's not the story here--the story here is that the GlibC people created the breakage deliberately and are hesitant about the idea of un-creating it. Whether the breakage is justified or not (I'm leaning not), that means everyone, all distros, in the end would be finding themselves distributing a GlibC that creates that breakage. Arch was just the first to expose the issue.

This is doubly not about Valve using Arch as the base for SteamOS because SteamOS is not a bleeding edge distro in any way. It just uses a heavily curated snapshot of Arch as a base, but there is no way it would find itself inheriting a problem like this.

View this comment - View article - View full comments

Quoting: ExpandingManKind of frustrating: I had tried pretty hard for months to get this game working on Epic (through Heroic and Lutris) but I absolutely could not get it to run. Then it releases on steam and it launches right away. This understandably makes me pretty nervous in general that I won't be able to get non-steam games running, which isn't a great feeling.

That strikes me as a matter of perspective. If anything more of a good news story. I mean, it almost seems that you're complaining that it launches now and Valve has our back (even if Epic most assuredly does not, but like, we knew that).

View this comment - View article - View full comments

Quoting: kalin

Quoting: GeamanduraLooking good, I'm so excited that we finally have LGBTQ+ platformers. Now we only need LGBTQ+ RTS and shooters and simulators :)

Why. Why the sexuality matters. I also don't understand what about this game is about sexuality

I was wondering about that last, but I presume there's some sort of occasionally referenced Princess Peach - type story, and both protagonists are same gender. Not that you'll normally ever think about that while playing the game.

View this comment - View article - View full comments

I wonder how many they will have sold by the time they catch up with pre-orders?
I think that horizon is starting to show in the distance--like, by the end of the year maybe they'll be more or less up to date, so you'll be able to just . . . order them, as in go on Steam and click purchase and lay down money all in one step.

And at that point it will finally start to be coherent to talk about sales figures. Not that they won't continue to sell units, but there will finally be some kind of relationship between how fast the things are selling and how many people want to buy one.

View this comment - View article - View full comments

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.

View this comment - View article - View full comments