Quoting: Linux_RocksI remember when I had a big chunk of my huge ass Steam library installed. So many updates when I'd boot up the computer. lol

(Yes, I usually shutdown my computer when I'm done and shut the monitors and speakers off too. The only difference from back in the day is no static covers to put on afterwards. Even in standby, it's still probably electricity pumping CO² into the atmosphere.)

I feel you!

About five years ago, I moved from a rural village with gigabit+ FTTH internet to the center of a picturesque Dutch fortified town. Surprisingly, despite moving to a much livelier area, I was stuck with an ancient 8Mbit DSL connection.

When my friends got back into gaming during COVID, I constantly needed to download new games. Since those downloads took hours on that slow line, I usually had to run them while I was away at work. However, I also try to conserve energy, especially after the war in Ukraine caused electricity prices to spike. To avoid leaving my computer running all day, I used my OpenWrt router or Home Assistant to wake my PC via LAN and handle the downloads on SteamCMD through SSH or Cockpit. It was the perfect way to get my games ready without wasting power. After the downloading was done, a simple shutdown command would make the PC go off again.

View this comment - View article - View full comments

This new remote download feature in the Steam Beta looks incredibly useful, but it honestly just makes me wish we could do the exact same thing directly through steamcmd remotely.

Being able to manage this on a TTY via SSH, or through a web interface like Cockpit, would be a game-changer. Even better would be an accessible CLI structure so we could easily wrap our own DIY bash/Python scripts or a custom web dashboard around it.

View this comment - View article - View full comments

Quoting: elmapuli saw this movie before, we dont have an great track record of backward compatibility and we cant know if its fixed now, we have to wait 10 years from now and if the things made now still work, that means we have backward compatibility... for things made years ago, but current stuff might still have issues, as new libraries are used that may not have the same track record.

in any case if wine can be stable then there is some stable basis somewhere, until it doesnt because any distro can break stuff on purpose, but the ones who do would be punished by the lack of users... i mean everyone loves snaps right?

in any case, even if an game work, the mods for it may not work, if an mod rely on changing something on a binary to work, and the linux version has an different binary because its native, we cant expet this mod to work unless we run the windows version of the game on wine insted of native, so yeah, wine/proton will still be used even in a future where all the games support linux natively.

The backward compatibility issue for native Linux software has largely been solved, but not just by the modern kernel architecture. While it's true that the kernel handling DRM/KMS and memory management (instead of X11) created a vastly more stable and secure hardware baseline, older Linux software usually broke due to user-space library rot (e.g., missing outdated versions of glibc or libssl).

The real solution we have today is containerization and modern dependency handling. Technologies like Flatpak and the Steam Linux Runtime solve this by running applications in isolated environments that provide the exact legacy libraries they expect, preventing host system updates from breaking them. Furthermore, the ecosystem now heavily utilizes translation layers, shim libraries, and wrappers to seamlessly route deprecated API calls through modern, performant backends. For example, Xwayland translates legacy X11 calls for Wayland compositors, PipeWire provides drop-in shims for legacy PulseAudio/JACK apps, and tools like Zink or DXVK translate older OpenGL/Direct3D instructions into Vulkan. Add in user-space standardizations like SDL3, Wayland, and PipeWire, and the software stack is more robust than ever.

You are entirely right about mods, though. Because memory hooks and DLL injectors are built to target Windows binaries, highly modded games often run better using the Windows version through Proton rather than the native Linux port.

Quoting: elmapulanyway, do we still need an audio interface for professional usage? or pipewire does the job?

Regarding your audio question: PipeWire absolutely handles professional, low-latency routing (it natively implements the JACK API). However, it is a software routing daemon. You still need a physical audio interface for hardware inputs like XLR microphones or instruments.

View this comment - View article - View full comments

Quoting: Stella

But I think we can do better with a native solution.

I hard disagree with this statement. Pretty much all existing Linux games suffer from various problems ranging from complete inplayability over control and gameplay/visual issues as well as crashes. Running games over Proton is vastly preferable to Native most of the time because the Windows API is much more stable than the Linux API. I myself have had so many issues with native ports that the Proton versions never have, that I've given up on them completely

You are completely right about the historical mess of native ports, but the "unstable Linux API" (or rather, ABI [External Link]) argument is based on an outdated architecture. Twenty-five to ten years ago, the ecosystem tried and failed to unify around the "Linux Standard Base [External Link]," which never actually provided a stable target for developers as it shifted goalposts continually. The Linux kernel itself has always been fiercely stable (adhering to the strict "we never break userspace" rule from Linus Torvalds himself), but what broke games in the past was the chaos of fragmented userspace dependencies, such as the glibc mess with conflicting "GNU-isms" across versions, and competing multimedia servers across different distributions.

Today, modern native Linux gaming bypasses that problem entirely through a completely new approach. First, the Steam Linux Runtime ensures games no longer rely on your host operating system's libraries. Instead, they run inside a frozen, containerized environment, completely bypassing the software rot that used to plague Linux ports. Second, hardware translation has finally been standardized. The universal adoption of PipeWire has permanently fixed the decade-long multimedia nightmare, elegantly replacing the deeply fragmented ALSA (ugh), PulseAudio, and JACK stacks with a single, unified audio and video pipeline. Combined with the newly stable SDL3, even older native games are retroactively forced to play nicely with modern Wayland desktop environments without the original developer having to update a single line of code. Proton/Wine is an incredible tool, but a properly packaged native game running within this modern architecture is now just as stable as a Windows binary, with zero translation overhead.

View this comment - View article - View full comments

Quoting: suchLooks very much like those Java DOOM and Wolfenstein rpgs.

Absolutely!

Those Id Software titles, like DOOM RPG and Orcs & Elves, were truly groundbreaking for their time on mobile phones. The way they combined those complex worlds with an engaging turn-based RPG system was brilliant. They have certainly remained very dear to me.

I am definitely wishlisting this one!

View this comment - View article - View full comments

Great hardware, but I'm sticking to open hardware projects like Ploopy. Once you get used to the freedom of open firmwares like QMK or ZMK on your peripherals, it's hard to go back to closed ecosystems. It is too bad, though, that open firmwares for wireless mice are still pretty much non-existent or broken.

View this comment - View article - View full comments

This is incredibly exciting news! I sincerely hope Valve plans to upstream their contributions, particularly the work done on FEX and the extensive ARM optimizations. Integrating these back into the mainline projects would offer huge benefits to the entire Linux community, not just SteamOS.

A key technical question I have is whether SteamOS 3.0 for the new Steam Frame remains based on Arch Linux. If it is, Valve's work on the ARM platform could significantly impact upstream Arch Linux and its derivatives, such as CachyOS. Regardless of the base distribution, I'm curious to know how these performance enhancements will be shared or integrated into other major non-Arch Linux distributions as well.

It's a huge opportunity for cross-distribution collaboration and advancing Linux gaming on ARM (and hopefully RISC-V in the future too)!

View this comment - View article - View full comments

Does anybody have an idea how this works? Does it use the Van Gogh APU or does it lean more on the VLV0100 EC?

View this comment - View article - View full comments

Quoting: eggroleThis is the old "think of the children" tactic, and sadly I bet it will work.

Sadly, you're right, and I suspect it’ll be exploited for even more sinister agendas like “Chat Control” or outright bans on encryption.
Ironically, that kind of overreach will just push things further underground, and what resurfaces there won’t be petty crime anymore.

Quoting: eggroleIMHO all this payment processing for adult content is the thin end of the wedge to eventually lead to the complete linking of real ID to digital identity. "If you want to buy adult games, provide your online ID to prove you are 18+."

Honestly, I’m not opposed to digital identity in principle. Most of us in Western nations already have one, it just isn’t universally exposed, except where the law requires it.

What matters is how it’s implemented. I’d much rather see something like the Dutch Idemix-based IRMA (“I Reveal My Attributes”) system, or the upcoming EU digital identity framework, where you can prove specific attributes (like being 18+ with a simple yes or no) without exposing your entire identity, or more than necessary.

That’s the sane, privacy-preserving way forward, not some government or corporate free-for-all with your personal data.

The fact (or perhaps even the reason) that these digital identity systems keep being delayed is, imho, deeply suspicious. It creates the perfect window to push through invasive measures like “Chat Control” or even outright bans on encryption, steps that would inevitably open the door for a free democratic state to slide into a police state, and eventually, full-blown authoritarianism.

View this comment - View article - View full comments

Ah, the UK, the nation that invented appeasement, and now perfects it by appeasing U.S. Big Fintech, trading the sovereignty of its digital storefronts for “peace in our time.”

Truly, some national traditions just refuse to die.

View this comment - View article - View full comments