How does it work on Android? One of my main use cases for Nextcloud is to be able to access some of my pdfs on my phone, the app seems to be focused on uploading which is something that while I do sometimes from my phone is much less often.

Warning, I’ve had an issue in the past where I couldn’t play a game (Deus Ex Mankind divided) because it needed a specific instruction set on the CPU (SSSE3). While not your specific case since the FX-8350 supports SSSE3 (I should know, that was the exact CPU I switched to to be able to play the game) there might be newer instructions sets that this old CPU does not support.

Also that GPU is older than what people like to remember, from a time where AMD was the worst GPU option on Linux. It’s very likely that the open source driver is good enough for that card by now, but there’s a good chance you might need to wrestle with the AMD proprietary GPU driver (fglrx) which is worse than the Nvidia one in some aspects and some distros don’t even package it anymore.

If you plug your Nvidia GPU that rig would be usable for gaming, I’m not sure what fps you would get as games keep getting updates and old hardware remains the same so old benchmarks might not be reliable, but I suppose it should run plenty of stuff.

You used Linux like Windows and got bad results, OP treated Windows like Linux and got bad results. The problem is neither OS but how familiar you are with it and their peculiarities.

That being said, GPU drivers are not a rough edge on Linux, only Nvidia drivers are. And even then it’s usually a single click/command to install the proprietary drivers if you need them, otherwise the open source ones work like a charm. This used to be more of a problem a few years back, when both manufacturers used proprietary drivers, but AMD ones are open now and therefore integrated into the mainstream kernel, so they just work.

Yes, but you would need to know to run that command, so it’s the same situation as the windows case where he didn’t know which drivers to get. So the argument is disingenuous in that it either ignores the case or he has knowledge on one OS that he doesn’t on the other. On the other side of the coin someone could be making a similar post saying in windows they just switched hardware, installed drivers and done, in Linux they spent hours trying to figure out how to install the drivers.

I’m not saying it’s hard (on any OS) but it requires previous knowledge on both (although to a much lesser extent on Linux since this only happens when switching GPUs and only under specific conditions).

Can you give me an example of which distro/hardware change gave you a black screen? Because unless it was Gentoo or something you built the kernel yourself a black screen is extremely unlikely. Unlike Windows which requires drivers for everything, in Linux the drivers are baked into the kernel, so any hardware change should just work out of the box (there are some caveats to get the best possible driver, but even the included driver should be more than enough for almost anything except heavy use on Nvidia GPUs).

I agree that on average the Linux user has more technical expertise than the average windows user, but that’s mainly because the average user doesn’t choose their OS. If you take into consideration only people who actually chose their OS, I think it’s very similar.

And OP talked about his experience doing that, the default windows driver gave him a crappy resolution, and he had lots of issues getting the right driver and making it work. You skipped all of those issues because you knew beforehand which was the correct driver, and pre-downloaded it.

This is disingenuous, if you had an AMD GPU on Linux and switched to an Nvidia card you would be using the nouveau drivers so you would need to install the proprietary drivers to get the best performance.

And lots of the same issues that are listed on the windows side could happen on Linux as well since they relate to connectivity.

I agree that the original post is dishonest, but your solution is exactly the same as what they said with the exception that you knew it would be a problem so you downloaded the driver beforehand. Had you not known that would happen the series of misfortunes could have happened to you too.

Because you brought up a non-proton related issue. It’s highly unlikely this is proton related, this is an issue on how the steam virtual keyboard and Skyrim interact, and since the keyboard doesn’t cause issues on any other game I think it’s very likely the culprit is Skyrim, and if that’s the case I want to know if the issue also happens on Windows.

Is it possible that the issue is within proton? Yes, but the problem you presented can be in multiple other places that proton can’t touch. For example if the game crashes on windows too then proton is working correctly, and even if it doesn’t it can still be something else besides proton, e.g. steam closing the keyboard in a different manner, Skyrim has had a famous bug where it crashes when you alt+tab away from it and come back on Windows for a long time, and opening a virtual keyboard on top of the game and going back is essentially alt+tabing, so I wouldn’t be surprised to find out that this is the same bug in Skyrim showing up with a different face.

PS: out of curiosity I went and loaded my old prisoner save, and named the character which is how many people reported the bug and it just worked, so even if this used to be an issue, doesn’t seem like it is anymore.

What happens when you do that? And does doing that on windows work? Because it sounds like an incompatibility between the steam virtual keyboard and Skyrim.

Ansible.

I use docker for most of the services and Ansible to configure them. In the future I’ll migrate the server system to NixOS and might slowly migrate my Ansible to NixOS, but for the time being Ansible is working with relative ease.

Yeah, I was talking about the community in the last paragraph. The tool makes easier official ports and also allows unofficial ones (which works as an encouragement to studios to make the port official).

You’re completely missing the point of this. Oculus Quest uses an Android OS, which means every VR game released for Oculus Quest is an APK, which means there’s a version of the game already optimized for a portable VR headset that can be run with Waydroid/Lepton. Valve is making the same move they did with the Deck, we can’t convince studios to build native? Okay, we’ll run whatever version it is they have already published.

This in conjunction with Fex makes it so that they should be able to run any VR game that could possibly be run in the limited hardware, and they’re giving studios a way to release a “native” version that they already have laying around for better performance (or even to make their first release on Steam).

And let’s not forget side-loading, most games on the Quest have already leaked their APK, they don’t care too much because they’re the only Android portable VR, but because the frame is an open platform people would be able to just install those files manually very easily. So if the studios won’t do the minimal effort to bring their games to the frame the community will. I was momentarily sad when I realized that robo recall (which I own for the Oculus Quest) is not available on Steam, less sad now.

You’re almost correct, but a sound bouncing off a wall sounds the same as something beyond it, or coming from a slightly different angle, just like how visually a reflection is “beyond” the mirror. Sure, you can try to calculate that back to the original location, but that’s not very accurate, nor does it tell you the origin of the sound, could be an enemy, could be a friend, could be random low sound spawns sent by the server to bait cheaters.

For the threshold I think it’s a lot smaller than you think, while a wall hacks that shows an enemy that will become visible the next frame is useful, it’s a lot less useful than current wall hacks.

As for the audio, you can absolutely randomize stuff enough that it’s useless to hacks but useful for players, because no person will hear a sound and know the exact source of it, only a general direction. Hell, most games don’t even do proper wall bouncing or other sound mechanics that would allow humans to pinpoint location in real life.

I don’t, this has never been a possibility for me in the last 4/5 houses I’ve lived unless I specifically bought a 3m long USB cable. I’m sure plenty of people do, but I don’t think it’s 99%.

I have mixed feelings about this. On the one hand I like the idea of AA because if the controller dies mid-session you can just swap them and keep playing, on the other this is easily solvable by having a dock like the 8BitDo Ultimate, which makes it so that the controller is always fully charged when you pick it up, so the only advantage that the AA had disappears, and it’s even more comfortable to have the controller always charged than having to get up in the middle of the play session to find new batteries. And the Steam controller has a charging puck, so it should never have the issue where AA are better. So my feeling that it would be better is not justified.

The other supposed advantage is longevity, since all batteries eventually die off, if it’s an external battery you just buy new ones and are done. Being internal makes it more of a hassle. But Valve has been very open with the repaiedness of their devices, so I expect this to not be a big issue, as long as the batteries are still being manufactured by the time the one in the controller dies off (which should take a lot more time to happen than regular AA).

A couple of things, first no, I don’t feel the latency of a Bluetooth controller. But also the steam controller will be able to pair to multiple devices, in one of the interviews one of the engineers said “The steam Machine has its own antena, but each controller comes with its own puck, we expect the common use case to be to plug that to your PC and use the steam controller in both devices”

If an enemy is outside your vision, but makes a noise, you cannot give that information to the client without revealing the enemies position.

Sure you can, for starters audio is a lot less reliable to pinpoint location than video, so the server can randomize the position somewhat and still be accurate enough. Not to mention that sound bounces off walls, so it’s not exactly wrong to give the point of origin of a sound as a wall nearby the origin or destination, and an even more advanced system could use ray tracing to calculate sound path and give you a fully accurate sound point that doesn’t reveal the source exactly.

If a player kicks a bucket across the map, the bucket flying through your screen makes it trivially easy to calculate the point of origin - and you know something happened there / player was there.

But again if you’re not sending the bucket position until it’s in FoV that doesn’t matter at all.

We’d be really really lucky if server side fog of war would be the kill-it-all solution to cheating.

It’s not the end all, but it does take are of whole categories of hacks.

I’ll reply to the server FoV there. Skill based matchmaking is hard to solve, but I think most games who have enough players to worry about anti-cheat to this level should have some level of skill based matchmaking in place, in my head that’s way more important than anti-cheat because even with cheaters the games are fun for everyone, and cheaters end up bubbling up into their own group.

Well, yes, but, let me counter with this:

You can completely remove wall hacks from the equation by doing some FoV calculations in the server, this completely solves that issue, there’s no client side hack that would be able to show you enemies behind the wall because the server isn’t sending them to you.

And to the other point, if the 20ms kill is bad but the 14ms kill is good, there’s space to argue that the cheater is worse than the players so you don’t really need anti-cheat so solve that, Skill based matchmaking takes care of that for you, he would eventually be placed with people who are better than him even with hacks.

Sure, server side anti-cheat can’t capture everything, but neither can client side, but server side anti-cheat can make it so that your client side cheats are pointless, because they can’t make you better than everyone, you have to remain averageish, and if you’re consistently above average skill based matchmaking will bump you up and up until you’re going to lose even with cheats or you will be playing against other people with the same cheats as you.

Let’s do some math here, they said:

More cheaters using Linux than legit users (…) .01% of all players base

Let’s do a quick math. The maximum peak users for Rust was 259,646 concurrent users according to https://steamcharts.com/app/252490 . Let’s assume 60% (more than half) of all the .01% users were cheaters, congratulations, you got rid of all those 16 cheaters… I haven’t played much Rust, but I’m fairly confident that there’s a bit more than 16 cheaters there.

And that’s without getting into the whole client side anti-cheat doesn’t work.