👍

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.

Great job! 👍

As someone who runs multitudes of Fedora servers with Nvidia+kmod build issues, I can say you’re fine to reboot.

Nvidia packages fail all the time, especially when there is an out of order issues, like if you’re updating a kernel before a reboot, AND also the kernel headers aren’t in place first.

Reboot, and if the drivers aren’t working (run nvidia-smi to check), just reinstall the updated packages and reboot, and it should be fine.

As a debug step, try running killall ibus-daemon before you launch the game. See if anything changes.

Blown away by the demo. Great artwork, awesome story, very funny. I’ll have to try the full thing.

Not sure what other type of computer aside from a Deck or Laptop that would be functional enough for “lounging” while computing though, unless I’m misunderstanding what you mean.

Steam Deck

There’s a few things at play here, but the main thing is that whatever Bluetooth daemon is running is likely running in userspace. Switch users, get a different PID and Bluetooth daemon.

It looks like Arch uses Bluez as root by default though, so is it possible you have another BT manager in the mix somewhere?

Give this a shot and see if it works. It’s pretty clever, and you won’t need to mess with much you may not understand yet: https://github.com/ctsdownloads/steam-drive-mounter-bu