

“We’re expecting console numbers this time, and then they developers will have to support it.”


“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


Lol. You have no idea what you are talking about about here 😂


Try Parsec. If it works as expected, then you have something wrong with your Sunshine config, or your available libraries. Post logs from Sunshine if Parsec works fine.


It just has some QoL automations centered around resolution config creation and Virtual Displays/Desktops. The internal bits and pieces are the same otherwise.


It is a fork…of Sunshine.
Build and run it the same way you would run Sunshine.
But that’s not the whole point of my post. Run ANYTHING else and get a comparison or some logging output. Right now you’re just assuming it’s a problem with Linux or your system as a whole, and you have no comparison to prove that. More info gets you better steps to solving your problem.


Apollo very much runs on Linux. It’s a fork of Sunshine: https://docs.lizardbyte.dev/projects/sunshine/latest/#️-system-requirements


I believe this is an issue with Nvidia’s more recent drivers and sourcing various libraries. See this issue here to get a sense of whether this is your problem or not, and try to get some log output to confirm and helps debug. That issue is not going to solve your problem, just help in debugging.
It would also be good to get a comparison from a different streaming kit to rule out networking issues. If you have Steam, try running a few games through Remote Play and see what happens there, or try Apollo and see if there is any difference.
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.