Just RMA it now. If it has SMART failures, you can provide the codes and they’ll replace it no problem.

EAC is the problem. It’s not that the game can’t run, it’s that you’ll be blocked from connecting to any servers.

This guide seems pretty dated. I wouldn’t recommend most things in here anymore, honestly.

No idea what you mean with the port assignment. You can run either on whatever port you want. Most residential ISPs block incoming on 80/443 anyway.

I’d use something more modern. Wireguard at the very least, but Tailscale’s implementation of Wireguard makes things extremely flexible and simple to manage. Tailscale or ZeroTier, there’s a few of them now.

Already, buddy. You come here looking for help and don’t take the advice. Keep strugglin’.

Because if you’re having stability issues, it’s NOT working well. The versions di mentioned is specifically targeted to work with Lutris, but the ones you’re running it on are not. Probably why you’re having issues.

Try just ‘Proton-GE’ (not the named version one), and not ‘GE-Proton’.

Don’t run with the latest release of any of the regular Proton versions, especially Experimental because it’s unstable by nature.

What runner do you have configured in Lutris for the Battlenet Client?

Ok…backup a second.

Are you launching your Lutris games through Steam all the time? Depending on how you’re doing this, it could certainly be the problem.

Can you show the launch command being used to start Battle.net if doing this from Steam? Does it seem more stable if you only launch through Lutris?

Vulkan is just the API interface to your graphics hardware. It’s not directly involved with any functionality of the Battle.net launcher in any way.

If the launcher is having issues, then it has to do with whatever is running that launcher. Can you explain more about how you have it running? Is it running under Proton/Lutris/Heroic? What are the actual issues you’re seeing? Any error messages?

The entire point of these Wine managers is that you don’t need to fiddle with the underlying Vulkan settings. The configurations for each prefix do this for you, and you tweak the settings there. You don’t want to make global changes to your Vulkan configs as you are describing unless there is a defined issue with your system as a whole, which it sounds like there is not. Only with this one program.

Sounds like a problem with the devs. Check ProtonDB to make sure.

This is not a thing because of Deck.

Were you launching a game that requires online presences? Kinda seems like it.

Want to provide some more context?

Sure, but that’s not the question here, nor is it really feasible to expect OP to know the technical challenges of doing so if they are asking this question in the first place.

An e-reader, so it’s unlikely to be of much use.

Can it run Linux? Probably already does.

Does that mean it can run a full desktop? Nope.

It has a 533MHz CPU and 256MB of RAM, so it can run a stripped down kernel and do the basics, but that’s about it. Even if you got XFce running, your not going to be running a browser or any kind of games. That’s even before you think about how you’d run the display driver.

Can’t believe I need to keep stating this around here, but Linux is THE most deployed OS on the entire planet. It’s not even close.

Whether it’s used for Desktop or not is irrelevant.

You’re using a service that is proxying your data. They can read all of it.

If you don’t care, then good for you. You’re still the product as being a user because whatever you happen to be serving may eventually become interesting to them.

If not, no harm done. It costs pennies to host a 24/7 load balanced reverse proxy. You just can’t do it yourself.

Not sure what you’re asking here, but are you talking about the voice part, the TTS pat, or the interaction?

This generally referred to as Key Rotation. It applies to everything from SSH keys, to API keys in running apps.

There are automated ways to do this with ease, but it’s very simple to do with a single script, and some sort of secure key/value store (bitwarden, Vault, etcd…whatever).

The process is basically something like:

1. Create a script that runs on cron to check for a key at your k/v store at an expected location, like /ssh_keys/host1-private-12.1.25 and /ssh_keys/host1-public-12.1.25
2. Deploy this script to all machines you wish to regularly rotate keys on and ensure running properly
3. Generate new keys and put them in your k/v store at some versioned location/path like /ssh_keys/host1-private-12.21.25 and /ssh_keys/host1-pub-12.21.25
4. Update your local script that regularly grabs these updated keys to point to the new version uploaded, bonus if your store can symlinkto some other locations like /ssh_keys/host1-private-current
5. Wait X period of time to ensure all hosts get whatever key they need

Your script can clear the old keys if needed but simply validating them in the access change serves the same effect. Up to you.