I've seen some threads pop up with questions about problems in Linux that aren't really problems of Linux.
For instance, something that Linux gamers get regularly - mainly because of the very poor quality of the Windows graphics drivers that are used in Linux as "proprietary" drivers, because mainly nVidia boycotts Linux native KMS driver development - is that a game can freeze on a loading screen or in a certain phase of the game.
Rust is the best example of that, it's often a nightmare to run in in Linux. But source-based games since the last update tend to do the same on non-US systems.
Well, it doesn't have to be a real problem, because Linux is very powerful.
In Windows, these problems would be solved by running the game with Administrator rights. This is like the stupidest thing ever for safety reasons, but it's a very popular solution. On a lot of linux fora, a similar solution is very often suggested, especially by proprietary graphics driver and DirectX gaming devs that have no clue about Linux, namely to start the game with root privileges from CLI, or with gksu, which basically means starting the game in the graphical shell without the need for root authentication, but with privileges. I sincerely hope that nobody ever does that. I see it all over the Internet, but it's really really really dumb. You NEVER EVER give closed source software root privileges, not ever, period! In Windows, it doesn't matter, admin rights or not, it all means nothing anyway, because only Microsoft has real root access, but in Linux, where the system belong to the user, and not some corporation, you never ever give root privileges to something that is not open source and from the official repos, period, no exception, just like you never ever install any software outside of the official repo sources or - if you waive the risk of installing from Steam - from the Valve repos. People that can make exceptions for open source software to this rule, know when they can make such exceptions, because they know enough about Linux, and they're experienced in using git, SVN, etc... if you don't know how to compile from source, don't know how to check source code, and don't know what git or SVN is, the only thing you should know is that you never should make an exception to this rule, and thus NEVER EVER install something from some website, like you would in Windows. And that includes official corporate websites, in fact, those are probably the most dangerous. You don't even install the Steam client from the Valve website, you install it from your distro's official repos using your distro's normal package manager.
It's also not necessary to elevate the privileges of freezing applications like in Windows, because there is a really easy fix. If a game locks up, it's almost always because there is a GUI process in the background and the screen is locked by the foreground process, and the background process prompts for user interaction, but the user doesn't see it. It's the same with Windows, but in Windows, there isn't a simple solution like in Linux, because it's not a powerful operating system. Some people even run games in a window instead of full screen in order to avoid freezes and lockups, or to be able to access other GUI elements, like for instance a communications app or a streaming app. In Linux, you don't have to do that, you can run the game full screen without fear or being locked out of your system.
So if your game or other closed source software freezes, what do you do: you switch TTY. TTY stands for "Teletype", which is short for "teletypewriter", and in computer terms, that just means "terminal". Any *NIX system (or POSIX compliant system, this also includes OSX), can run multiple terminals for interaction with the computer system. Every interaction with the computer system goes via a terminal in *NIX systems. So when you switch to another terminal, you basically go behind the back of the display server that runs in the terminal you were using, directly to the system via another terminal. Now if everything is configured as it should, you shouldn't be able to do a lot in a different TTY, because it should be locked for security purposes when running closed source software, but you don't actually have to be able to do anything in the CLI, just the fact of switching back and forth to another TTY, will cause the display server to unlock the locked screen, and it will show you the user interaction prompt, that you can then normally address, and the freeze is solved.
Now how do you switch TTY? Simple, you type Ctrl-Alt-Fn, whereby n is the number of the TTY you want to use. Normally, the display server will run in TTY 7. So for instance your game freezes because there is a security warning in the background that you can't click away... press Ctrl-Alt-F2 to switch to TTY 2, and you'll see a command prompt, but you don't need to use that, just as soon as you see that CLI screen, press Ctrl-Alt-F7, and the system will switch back to the X server, but the processes will be unlocked from the screen, and you'll be able to address the issue, and continue playing the game as if nothing happened. Switching TTY will also not end any processes, or crash applications, it just won't, it's perfectly safe to do. It will just make the system reset the graphics subsystem mid-session (try that on Windows lol), without breaking anything. It will also temporarily disconnect the input devices from the X session, so whatever you type, won't affect your application.
Cycling TTY can also be helpful if the Windows graphics driver in Linux is causing artefacts or stutter. Sadly, these drivers are full of problems, and they contain scripts to suppress Linux security warnings and stuff to even make them work in Linux, but often at the cost of not emptying a buffer when it should be emptied, or causing a window frame to load in the graphics memory where this shouldn't be there, etc... bugs and bad quality galore. Sometimes, using the Linux native open source KMS drivers is not an option because for some games, more graphics performance may be required. By cycling TTY, this will just stop, because the buffers will be emptied and instances that claim foreground will be reset, and the artefacts will just disappear, the stutter will disappear, the gaming experience will be perfect again.
You can't solve the fact that the Windows drivers are crap. Those proprietary drivers are closed source, and there is nothing you can do about it. There just not made for Linux, they are an emergency solution. It's possible to game with open source Linux native KMS drivers in bleeding edge distros for Intel and AMD graphics hardware users, but it's completely impossible for nVidia hardware users and - for the moment and until these distros catch up - also for non-bleeding edge distro users. So don't flame the distro maintainers, don't escalate privileges on these fundamentally unsafe (because closed source) applications, don't panic, just cycle TTY and let the power of Linux deal with the problem...
If anyone else has good tips on where TTY switching can come in very handy in practical daily use, feel free to post them here.