I mean…once they have this going, there’s nothing stopping that. It’s essentially the same thing, except the hooks for Mac/Win for the desktop. Linux will already be ready to go. I just haven’t heard them mention it is a point of release is all.
I’m…not sure what you mean. They’ve just compiled SteamOS and it’s base for arm64. There was nothing stopping that from happening previously. The majority of the client code is closed, and that entire piece of SteamOS is weaved into the OS itself. So they’re just distributing arm64 builds if SteamOS with the client code, not commiting to a standalone client being distributed, unless you’ve seen that somewhere.
Support meaning in their build system. They’ve already added that as a build option awhile ago. Just means you can set a flag to build for more platforms now, and they have arm64 machine types to handle the builds.
Devs still need to do optimizations to support this in most cases. Some games based on open frameworks won’t have much to do but flip the switch.
No, they are building a translation framework for x86
Grammar and formatting, ma dude. This is painful to read.
If you’re reading reviews on Software Manager, you don’t want to be messing with jails.
Just use Flatpaks, and install Flatseal for permissions control over individual packages. They are sandboxed, but with permissive defaults set by the devs, so you can use Flatseal to lock them down, then set permissions you’re comfortable with. If it breaks something in that one Flatpak, then just reverse your permissions changes. Simple.
“We’re expecting console numbers this time, and then they developers will have to support it.”
I think you probably need to understand the underpinnings of what Valve accomplished over the past few years to understand why the Frame is useful.
Essentially, it’s a Deck strapped to your face. Same OS, same everything, just different hardware platform.
Valve spent the time to revamp SteamOS in order to make it more portable to various devices, which are now launching. Couple that with their efforts on Proton, and you have an entire ecosystem with very little in the way of preventing people from adopting these devices with their ease of use.
Steam Deck was just sort of the appetizer and test launch to gauge interest and build a fully functional hardware development and support vertical in the company, and it was wildly successful. I guarantee (if they can get the price right) that the Frame will sell WAY more units than the awful Vision Pro. I honestly think people might adopt this over buying another version of the Deck if it’s comfortable.
Some things I expect to happen with the Frame launch:
Sounds awful and tedious
Opentofu is Terraform 🤣 I generally don’t throw that out there to prevent confusing people, but I prefer it, honestly.
Packer builds images you can upload to cloud platforms.
Terraform/Opentofu executes API calls to orchestrate spinning things up and down.
Cloudinit is the native built-in bootstrap framework of instances themselves that all the major cloud providers support. It’s what executes as “userdata” as some call it. Check your cloud provider docs for how to hook it in.
Use Terraform + Cloudinit scripts if you’re using a cloud platform, and make sure you version everything or use Packer to make versioned images.
Don’t use “echo”. That’s akin to saying “Print everything after this echo command to the terminal”, so it’s just outputting the stuff after echo as if it were text.
All day everyday. Why click through a GUI when I can slam out a command in 1/4 of the time to see what my resources or doing, or if something is acting weird. Watching logs tail in a terminal is always going to be faster and smoother than GUI as well. Debugging things as well.
👍
It may not be config related, by libraries missing or in the wrong location, hence, why I’ve been asking for logs from Sunshine.
🤦 It’s not necessarily about bugs in Rust-lang, though you can lookup CVEs if you want. The point is that ANY software, by default, will have bugs and exploits. Doesn’t matter if it’s Rust or C. You can exploit at the core, or at implementation. It’s just matter of time and effort, as they say.
Just flat out saying Rust, or software written in Rust is be default is secure, is a fool’s assertion. Sure it’s LESS LIKELY to have a memory exploit, but that’s where that assertion ends.
Improbable. Everything has bugs that surface. See my other link, or look yourself. There have been plenty of security fixes for Rust. It’s not bulletproof, just like anything else, just less likely specifically for certain memory attacks to be vectors.
Again… IMPROBABLE
WOW. No, it would make it improbable. It’s not like there can’t be zero-days for Rust, bud. This particular attack vector deals with memory handling, and sure, Rust’s main feature is memory security and management. Doesn’t mean there aren’t bugs to exploit there.
https://linuxsecurity.com/features/rise-of-rust-based-malware
Just don’t run this version of Proton with this game.
The reason they make all versions of Proton available at all times is because the rolling Proton version may break game configs for various reasons, in this case it looks like a Vulkan rendering queue issue where the call is blocking: https://docs.vulkan.org/refpages/latest/refpages/source/vkQueuePresentKHR.html
You can check ProtonDB to see if anyone has a workaround for newer versions of Proton, but it’s mostly unnecessary unless there’s some specific features a specific point release you care about. Just pin the game to a working version and go.