I dunno, I expect the Deck to last far longer than the average console if anything. It’s a PC, so the games are pretty much guaranteed to keep coming for decades to come, as they have for decades past.

The hardware will fall behind, so I think the point where the newest Triple A games won’t be playable will come within a few years, but I bet whatever visual novels or pixelated indie games release in 2035 will still run just fine on it.

Plus, it’s designed to be repairable, unlike most consoles. And even if Valve stops maintaining SteamOS for the Steam Deck, you’ll still be able to install other distros, so software support isn’t something I’m very concerned about either.

No romhacker or homebrew developer worth their salt will touch any of this. Using leaked material is legally significantly more dangerous than REing. I look forward to seeing the TCRF pages, though.

you don’t actually have to do that. for the most part you can just run everything in the same prefix. it’s what I usually do.

Hm? Wayland has VRR.

FIFO and commit timing are big for gaming. IIRC the lack of those protocols was a big reason why devs didn’t want to enable Wayland support for SDL3 at first.

What exactly does Valve stand to gain at all from funding a CUDA compatibility layer targetting mainly machine learning software? They’re a video game company. Arguably the most gaming-centric thing CUDA is used for was explicitly discarded in the blog post (“Raytracing is gone”).

Machine learning is massive now and there are many companies who could be interested in funding this kind of project. I’m pretty skeptical it’s possible to make any good guesses with what little info we have.

History:

1. ZLUDA starts as a project to make CUDA work on Intel GPUs, with funding from Intel.
2. Intel pulls funding, author manages to get funding from AMD instead.
3. Development of a new version targetting AMD GPUs happens under closed doors with the informal agreement that the source code will be publicly released if AMD pulls funding.
4. After a couple of years, AMD pulls funding and the source code for the new version is released.
5. Development continues in the open for a few months, albeit at a slowed pace.
6. AMD goes back on their word, claims previous agreement wasn’t legally binding and asks that ZLUDA source code be taken down.
7. Author reverts codebase to its pre-AMD state, looks for new source of funding.
8. ZLUDA’s Third Life
9. Anything regarding NVIDIA involvement is pure speculation and should be treated as such.

Man, this guy does not give up. Respect, honestly. Hope for the best this time.

Huh, just realized Yuzu was GPLv3. That’s weird. Citra was GPLv2 and Yuzu is a Citra fork. Some of the Citra devs were Yuzu developers, but not all of them, so I wonder how they handled the relicensing. Yuzu had a CLA attributing copyright to the creators, so that wouldn’t have been a problem, but Citra had not such thing.

I mean, all of these emulators are already very well archived and available from several sources, not to mention downloaded to the devices of millions of people. I highly doubt we would be in danger of losing any of them even if Nintendo were to sue literally all of them overnight. Well, except for things like Github issues and pull requests, nobody bothers to archive those unfortunately.

But yeah, IMO the danger is moreso that the attacks are leading to a massive chilling effect and loss of developer talent in the emulation community.

What operating system do you use? On Linux I use Amarok which is great, but afaik there’s no up-to-date versions of it for other operating systems. It should have everything you want dunno about some of these tho like the semicolon stuff. Strawberry is a similar player that works on other operating systems.

try disabling any krunner plugins you don’t need. that should make things faster.

Sketchup has always worked pretty well with Wine. It’s always just been installing a couple of things with winetricks (like vc runtimes) and then it usually works fine.

Uh, no. Not the majority. Not by a long shot.

Kinda insane how many people in a nominally open source community are defending this guy for switching to a proprietary license. If DuckStation gets shut down then I say good riddance. It is not the only PS1 emulator in town and I will not miss the endless flow of Stenzek-related drama.

What problems do you anticipate? Wine, which Proton is just a modified version of, implements file dialogs. If it didn’t, just about every application that isn’t a game would be broken. Needing to open files is pretty ubiquitous, after all. You need file dialogs for that.

It isn’t significant. Wine already supports the vast majority of MediaFoundation codecs with GStreamer. This is just an alternative backend that uses FFmpeg instead of GStreamer. GStreamer already has an FFmpeg plugin, so this doesn’t add any new codecs to the table. It seems there’s just a long term plan to move away from GStreamer for whatever reason.

Wine’s MF support used to be much worse, which is why Valve had to do their workaround shader hack. Not sure what exactly the current status on that is, but I do know things like mf-install or Proton-GE are rarely if ever necessary anymore, even with non-Steam games (which I have plenty of).

Well, Steam and Proton both already run on top of FEX or Box64 on ARM Linux, but it’s nice to see an official effort from Valve.

Also, does ARM still have better battery life when all of the machine code has to be translated from x86? That adds a not insubstantial amount of CPU overhead, which does hurt battery life.

And perhaps most importantly, is there any ARM chipset out there that can deliver performance on par with the Steam Deck’s CPU (even after factoring in the overhead of the x86 JIT) at a viable price for a Steam Deck successor?

I’m surprised you could even run a Linux distro with X11 and KDE1 on 8MB of RAM.

Qt1 came with two default themes. One of them mimicked Win95 and the other mimicked Motif. KDE1 defaulted to the former in order to look more familiar. To this day, the “Windows 9x” theme still ships with Qt and can be selected on any Plasma 6 install. Starting with KDE2 they started using their own custom themes for everything, tho.

GNOME 1 actually looked very similar, which isn’t surprising because its main goal at that point was to offer a replacement for KDE that didn’t depend on then-proprietary Qt. GNOME 2 and KDE 2 is when they really started building a distinct identity.