Quoting: vic-bayWhy doesn't Steam just collect hardware data automatically, are there any legal issues with it? I'd like to see smooth statistics without sampling swings every month.

This is not really a problem of sampling swing, it's chinese new year. Every year, there are massive rush of work in China / southeast asia until mid jan, then relax time starts, and people suddenly play many more games, with many probably only playing at this time. This culminates with chinese new year's golden week. Since Linux is not used much for Gaming there, you automatically see a huge drop at that point. So factually, during that period, there are way more Chinese players, and they factually use windows more than they use Linux.
It's true that a yearly or at least quarterly average would give a broader picture though.

View this comment - View article - View full comments

Quoting: GustyGhost

Quoting: 3zekielPoor x86, why so much hate ?

It is justified. The x86 duopoly have universally deployed what I would consider to be rogue silicon in the form of Intel ME and AMD Platform "Security" Processor, effectively extinguishing owner control and true device ownership under x86.

It used to be that you could have stuck with AMD, but then they followed suit and did their own "Intel ME".

It was once within reach to use me_cleaner script but Intel have continually pushed the feasibility of this out of sight.

Remaining on old, pre-ME/PSP CPUs was viable for high end gaming only a few years beyond the implementation of these anti-features.

Intel bought out VIA, eliminating any hope of real competition. VIA's last foray into performant x86 died with Isaiah II.

It is as though some force is railroading everyone into computers which ultimately answer to somebody other than the user.

A savior couldn't come soon enough. I'd lived on Open POWER for several years and am dabbling in the emerging RISC-V gear. The real shame is that projects like FEX and Hangover (who once supported truly free ISAs such as POWER) had dropped ppc64 support and currently no support for RISC-V.

The interim "solution" is to take a leap of faith that BIOS vendors of AMD boards are being honest in their PSP disable switches actually doing what they claim to do. Just a "trust us, bro. Communication with the PSP has been severed". And ARM is no panacea as they have their own "Trust"Zone rogue silicon. It is truly a dismal situation.

This is fair, but trustzone on arm isn't really any better in term of ring-10 than Intel/AMD.
I do agree w/ you that openpower is superior on that front. As for RISCV.... that will completely depend on the vendor. Implementing a "trusted core" is sadly all too easy (and not dependent on ISA either). If a RISCV vendor also wants to enable this in their system, they will. Fingers crossed that a fully open CPU might happen once again indeed, and I would believe in RISCV vendors more than in ARM for this.

View this comment - View article - View full comments

Quoting: ExplosiveDiarrheaGood, x86 has to go away.

Poor x86, why so much hate ?

Jokes aside, I think that having choice is very good, and I am all for translation layers being well funded / developed (it's also magical to be able to dev for ARM/RV32 from my workstation with just a container).
X86 does have its nice sides when you have to go down to ASM though. I am "fluent" in rv32 too, but x86 is just well... better, easier to write, and more importantly, to read. I know not many of us have to go that low, but for those who have to, x86 is nice.
For pure perf/efficiency, there is really not much difference on the ISA. x86 has a bit of crust, but it is very well designed, so the decoder is really not bad. CISC decoding made some insane progress since the 80's. And the N-wide issue engine, with reordering and friends takes wayyy more space (and timing depth) anyway.
ARM m1 and co dominate more because they have integrated the memory on die. x86 can do it too (Intel did it on last gen).
And x86 could also do in-order if needed, albeit for embedded indeed, the CISC decoder tax might become relevant again (if you have a dual issue, in-order core, yeah the decoder might hurt a bit).

View this comment - View article - View full comments

I think the anti-AI crowd is in for a rude awakening. While I often hear people saying they don't want AI, at the end of the day if the game (or whatever) is good enough, the consumer will buy it.

How many people don't have a phone because of some exploitation used to mine or manufacture it? Almost none. And this is rationally WAY worse than some AI slop. People like to virtue signal they care, but if the product is good enough, the consumer will buy it.

AI will be the same. If (and I think this is a when even though I am no fanboy) AI gets "good enough" people will slowly stop complaining and buy the fruit. Will there be the odd holdout? Sure. But, and I can't hammer this enough, if the product is good enough, the consumer will buy it.

I hate how AI is being shoehorned into everything these days as much as anyone, but I'm also sure there is a way to make products people actually want with AI.

For me, the issue is not so much AI use in and out of itself. I mean it's a tool, and it's legit to use it (same as using pre bought assets). The problem is more the amount of slop that will storm the stores because of this. But I guess it will self regulate after a while, like for ebooks.

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: sarmadSo, compared to the Steam Deck this has higher specs (CPU/GPU, screen resolution screen refresh rate) and smaller form factor, but in return the Deck has better screen, likely better battery life, and I guess slightly lower cost.

I suspect the Deck has better ergonomics as well.

Just from the view here, analogue sticks on this one are asymmetric, which is already vastly inferior compared to the deck... Never understood this kind of controller design. I remember first Xbox had same kind of weird analogue stick placement, and see others with it from time to time.

View this comment - View article - View full comments

Quoting: fearnflavioGreat news!
Now all I want to know is FSR2 on Wine/Proton/Gamescope when? 😁

I'd say that it won't happen, as time based algorithm require integration inside the game engine, so as to obtain the movement vectors. It _might_ be possible to infer them from APIs side, but I wouldn't count on it.
It might end up in Godot3D though, and maybe directly in all major engines.

View this comment - View article - View full comments

Reduced startup time for users with tens of thousands of games in their library.

How do you get there ? Too much humble bundle ? :P

View this comment - View article - View full comments

Working here too, quite welcome. I do prefer to play the native version when it exists, albeit I did not exactly plan to play it again but well. The 5 months delay is still clearly not optimal, but better than nothing.

View this comment - View article - View full comments

Quoting: CatKiller

Quoting: user1What's interesting from those screenshots is that even though the kernel is still 5.13, AMDGPU version is "DRM 3.45" which is from one of the latest kernels. But yeah, I wonder what prevents Valve from updating the whole kernel.

I suspect that they've got a big directory of patches, and they're finding it less painful in the short term to just add another entry in that directory rather than rebase all of them on a new kernel. They can ask Google about how that works out in the long term, of course.

My understanding was that they tried to upstream those patches ?
I do agree that long term this is a bad decision, but at least compared to android they only got a limited set of devices to support.

On another note, I wish they would add VPN support in the base image, currently there are no clean ways to support VPNs, except remove the base image read-only protection, or using Distrobox. Hope this changes.

View this comment - View article - View full comments

Quoting: denyasisQuestion, I'm not familiar with snap/flatpack, but if it keeps everything in the container, does that mean it limits what it can access outside the container? Like prevents Steam from reading the rest of my /home partition for example?

For Flatpak, indeed, it will protect your /home from Steam reading and writing anywhere it wants. You can of course add supplementary paths, notably with "flatseal" app, that's what I do with my library being on another drive than my /home. You can also add paths as read only, as an example for music access.

For snaps, depending on what the application packager does (enable full home access by default or not), it should also protect your /home. I also remember that snap has no support for fine grained permissions (allowing one specific folder). At least from the last time I used it. And there is no "flatseal" equivalent for easy management of permissions.

View this comment - View article - View full comments