They will run Linux, but you might fry them if your fans don’t work properly.

The EFI will control the fans just fine.

https://mapgenie.io/

Or what do you mean?

Yuzu is also a citrus fruit, so it at least makes sense.

Does the CLI still work? If so, you could download and play all the Windows 7 compatible, DRM-free games in your library just fine. Alternatively, if you already had these games installed, they’ll work fine without launching Steam first.

The feature itself is great. It records the last two hours by default and lets you easily create clips from that. The editor is right there in the Steam overlay, it’s pretty great.

I only used it under Linux, and that’s where I’d say it is still very much a beta experience. I have an AMD Radeon 7800 XT. Most of the time, Steam picks up on its hardware acceleration - sometimes it doesn’t. When it doesn’t, it falls back to CPU encoding (obviously) which occupies around 3-4 cores on my 7950X3D to record 3440x1440 at the highest quality setting. GPU encodes are H.264 even though the GPU is perfectly capable of encoding AV1. Performance impact ranges from almost zero to as much as 30%, which seems a bit excessive. On some games that have a splash screen (Sea of Thieves for example), all it will record is said splash screen, even when it’s not shown anymore: you get gameplay sounds, but the video is just a static image with mouse cursor artifacts. It didn’t record sound from one of the microphones I tried. After swapping it out for a different one, my voice is being recorded. At least one session the shortcut for saving a clip just resulted in an error sound instead of a clip being saved.

So it’s a bit disappointing so far. Yeah, Linux shenanigans and relatively small user base, but Valve out of all companies should treat Linux as a first-class platform. Yes, they do a lot for Linux, with Proton and whatnot. But ironically Steam itself is only in an “okay, it kind of works” state. No official packages for anything but apt-based distributions and Wayland (scaling) support is meh at best.

It did seem to work a lot better on the Steam Deck with very little performance impact in my short testing, so there’s that.

Not sure if you still encounter the issue, but I finally did some trial and error.

It doesn’t seem to be related to the AMD GPU, as I briefly swapped it out for an Intel Arc A750 and had the same issue. I then went ahead and tried disabling most onboard devices of my mainboard (ASUS ROG Strix B650E-E) and sure enough: that fixed it. I then re-enabled them one by one, trying waking the PC from sleep each time and narrowed it down to the on-board Bluetooth.

Do you happen to have a mainboard that has the “MediaTek MT7922A” (or AMD rebranded variant “AMD RZ616”) Wi-Fi/Bluetooth card? If so, try disabling the Bluetooth portion of it in the BIOS.

Let me guess without reading: kernel-level anti-cheat?

Include adding kernel level anti cheat to that. This should just give us an option to get a full refund.

I think I have a simple function in my .zshrc file that updates flatpaks and runs dnf or zypper depending on what the system uses. This file is synced between machines as part of my dotfiles sync so I don’t have to install anything separate. The interface of most package managers is stable, so I didn’t have to touch the function.

This way I don’t have to deal with a package that’s on a different version in different software repositories (depending on distribution) or manually install and update it.

But that’s just me, I tend to keep it as simple as possible for maximum portability. I also avoid having too many abstraction layers.

That’s mostly down to Teams though (being the bloated web app that it is), and not the underlying operating system.

When talking about the kernel, Windows actually skipped 3 major versions iirc from the top of my head. Windows 8 was Windows (NT) 6.2, and Windows 10 skipped that version number to, well, 10.

Why when a simple alias will do?

I also experienced less “hiccups” since switching to Linux with KDE but I’d like to know on what combination of hardware and Windows you experienced anywhere close to an average of 1s response time to “any input”.

iFixit rates it “Difficult” for the Steam Deck OLED and says the time required is 2-3 hours:

https://www.ifixit.com/Guide/Steam+Deck+OLED+Battery+Replacement/168676

This is a slight improvement from the original Deck’s estimated 2-4 hours:

https://www.ifixit.com/Guide/Steam+Deck+Battery+Replacement/149070

It requires removing quite a few parts but the most annoying part is getting rid of the adhesive. It doesn’t have easy-to-access pull tabs or whatever.

They can certainly improve this. Either add pull tabs to the adhesive strips, or better yet use the mechanism from the iPhone 16 where you apply voltage to the adhesive to make dissolve/no longer stick. Or even better make it a screw-in battery without any glue whatsoever. Then update the routing of several cables so they aren’t in the way of removing the battery.

Understandable.

What I will say though is that I personally wouldn’t mind regular spec bumps at all. The Deck isn’t exactly a cheap device and to get the “latest and greatest” for your “investment” at any given point of purchase would help longevity.

But as I said, in this case it makes a lot of sense (for Valve). SteamOS is still under heavy development, even more basic stuff such as the update mechanism and also power management is something they’re still working to improve.

They also use a custom APU designed in collaboration with AMD, and these designs cost a lot of money. It’s not just a rebranded 7840U like the Z1 Extreme for example. This custom design makes a lot of sense in terms of focusing on gaming performance and efficiency, and it clearly shows in (very) power limited scenarios.

Either way, I wouldn’t be surprised if we see a new Steam Deck based on Zen 5 and RDNA 4 with another custom designed APU sometime in 2025 or early 2026. Zen 2 is really starting to show its age and Zen 5 is a solid leap even over Zen 4 (not talking about desktop CPUs here, but Ryzen AI 300). RDNA 4 will likely improve quite a bit over RDNA 3(.5) (with the current Deck having RDNA 2) and include some type of hardware-accelerated machine learning upscaling with FSR4, which could make a lot of sense on the Deck as long as enough games support it.

I’d also like to see a few other improvements. The OLED display is great in many aspects, but VRR would be a great feature to have. Internally I’d like to see an easier way to swap the battery, maybe using similar tech to what Apple does with the iPhone 16’s battery. Currently, swapping the battery is one of the most complex repairs on the Deck, but it’ll also be the most common a few years down the line when all these batteries really start to show their age.

I think we’ll get at least one more x86 Steam Deck generation before it moves to ARM (if it moves to ARM at all).

The Snapdragon X isn’t anything to write home about when it comes to efficiency under load, with the newest CPUs (with iGPUs) from AMD and Intel keeping up or maybe even exceeding it.

Bitwarden keeps working just fine.

I’m no expert here, but I’m pretty sure branch prediction logic is not part of the instruction set, so I don’t see how RISC alone would “fix” these types of issues.

I think you have to go back 20-30 years to get CPUs without branch prediction logic. And VSCodium is quite the resource hog (as is the modern web), so good luck with that.

Sorry, I don’t know of a guide for other distributions.

Nvidia might be selling the shovels to the customer during this gold rush, but TSMC is making them.