I want to start off by saying I did not read the article; The topic surrounding secure devices while traveling has been on the rise in recent months so I will present some solutions which I believe all should take note off. I believe to obtain and maintain a truly private and secure mobile phone we must all be using a GrapheneOS device. However, for those of us who are still using iPhones I present solutions for you as well. Here are a few things to consider when traveling across borders:

• GrapheneOS Devices

If you are even the slightest bit of a privacy enthusiast you likely don't need an introduction to GrapheneOS so I will attempt to provide a succinct summary on why I believe GrapheneOS devices are the best phones to carry when traveling.

I believe GrapheneOS devices are the most private and secure mobile devices to have; Ironically they only work with Google Pixel devices, however this is not without good reason. Google Pixel devices offer superior hardware security than most Android devices on the market, which is why GrapheneOS will only work on Pixel devices.

GrapheneOS utilizes the robust hardware security features that Google Pixel devices offer such as the ability to re-lock the bootloader after installation. Typically, uploading a custom OS to an Android device requires you to unlock and disable the bootloader. After the OS is installed you must keep the bootloader disabled in order to continue using your custom ROM. This is horrible for your security. If someone has physical access to this device they can upload malicious software; likely without your knowledge. Having a locked/enabled bootloader is paramount to your privacy and security especially when crossing borders into foreign countries.

GrapheneOS has the upper-hand when it comes to this issue. After installation, not only do you re-lock the bootloader, but GrapheneOS will detect modifications to any of the Operating System partitions and prevent reading of any data whatsoever. The authenticity and integrity of the OS is always re-verified upon each boot. If you wanted to unlock the bootloader of a GrapheneOS device you will not be able to do so without completely erasing every piece of encrypted data on your device.

GrapheneOS has been tried against many of the forensic machines that Law Enforcement/ TSA/ Border Control use such as Cellebrite. To my knowledge at the time of writing, there have been no known cases in which Cellebrite was able to succeed in cracking a GrapheneOS device in a BFU (Before First Unlock) state.

• BFU (Before First Unlock)

When you first boot up your phone, you are required to input your password to access your phone's data. This is known as a BFU (Before First Unlock) state. After this initial "first boot" you enter your password which is then stored in your phone's RAM. This is known as an AFU (After First Unlock) state. Storing your password in RAM is necessary because your device is constantly decrypting information on your disk in order for your device to "compute". When your device is in this AFU state it is much easier for your device's password to be confiscated because the password to decrypt your phone's contents is stored in RAM. Simply rebooting your phone without entering your password will put your phone in a BFU state where it will remain until you put in your password. These same tips also apply to other devices such as laptop computers.

• Strong Passwords

On the topic of BFU (Before First Unlock) it is important to talk about strong passwords. Although your phone may be in a BFU state if you have a weak password it is only a matter of a short while before your device is cracked. A typical 4 to 6 digit pin is trivial to crack. Use either a very long and complicated pin or a very long and complicated alphanumeric password/passphrase; preferably the latter. Your password doesn't need to be super complicated just make sure it's long and memorable.

• iPhones

If traveling with an iPhone I highly recommend you look into Phone Pair Locking. For the sake of my fingers I will refer to Phone Pair Locking as "PPL" from now on. PPL was designed for businesses to deploy numerous iOS devices with the same configurations. PPL is done through a MacOS exclusive application known as "Apple Configurator". Apple Configurator allows businesses to configure permissions as well as place restrictions on iOS devices. What does this mean for us? It means we can configure our iPhone so we never have to worry about forensics again. Note that PPL is best enabled on a new device because enabling this will result in a complete wipe of your phone and you will NOT be able to restore from a backup. PPL creates a trusted relationship between your iOS device and a MacOS computer. This means that the only computer you will ever be able to transfer data to while plugged in via cable is the computer which you have setup PPL on. PPL will not allow a forensics machine to analyze data from an iPhone. PPL will not allow a forensics machine to copy any form of data for later inspection. PPL eliminates the threat of any forensic machines from being able to access any data off your phone.

I apologize for keeping this section brief but there is more we need to consider. Do not travel with the same computer you have set up PPL on. That computer is your key into your device. Leave the key at home and forensics can never use your computer to access your phone's data. PPL is NOT a replacement for strong passwords and BFU state, it is an additional feature which you should enable to ensure that your device remains secure. Another thing to consider is Apple Configurator is only available on MacOS devices. I assume you can use a MacOS Virtual Machine if you do not own a MacOS device, but I have not attempted this so I do not know. Unfortunately PPL is ONLY available for iOS devices. To my knowledge nothing similar to PPL exists for Android or GrapheneOS devices. Because of PPL I actually consider iPhones a decent option while traveling.

• Additional tips

Preferably use a secondary device. Purchase a new device specifically for traveling and keep a very minimal amount of information (if any) on it. In the event Law Enforcement is not able to crack your device they may just outright confiscate it and you will have to say goodbye to your phone. Be wary of what clothing you wear and what stickers you have added to your devices (if any). If your clothing expresses political affiliation or you look like a crypto shill with BTC stickers on your laptop and a Bitcoin shirt and hat you may be probed and questioned by overly zealous Border Agents because "you are carrying more than 10 thousand dollars across the border". This may result in confiscation and or secondary inspections. Try to wear plain clothing and remove or cover stickers that you think could possibly result in issues.

• Conclusion

I would like to apologize for making this post extremely long, it turned out much longer than expected. Since I've opened this can of worms add a comment to this if you want me to write a full guide. I have excluded a lot of information in an effort to keep this post as short as possible. But if I write a guide I will include everything with absolutely no stops.

I've had this exact same issue with a Nintendo Switch Pro Controller; IIRC, my fix was disabling Steam input.

The PC port of Batman Arkham City was horribly implemented and littered with issues involving, DirectX11, Nvidia PhysX, and .NET.

If the pre-game launcher/menu launches (the launcher that displays, Play, Settings, View ReadMe File, Exit) go into Settings and disable anything related to DirectX11 and Nvidia PhysX.

If the following doesn't work you may need to install an older DirectX version (DirectX 9 I believe) and/or edit a PhysX DLL file. Batman Arkham Asylum has very similar issues as well, I believe solely installing an older DirectX version fixes it though.

Take all this with a grain of salt because it's been a very long time since I've played Batman Arkham City.

Flatpak's security and sandbox has gotten much better in recent years. I've been using Steam via Flatpak for a while now and haven't run into any issues yet, other than not being able to make desktop shortcuts of my games.

I use Flatseal (another Flatpak application) to further restrict my Flatpak's permissions) The default Flatpak permissions for Steam aren't bad IMO (at least when compared to other Flatpaks) but you can tweak it to your liking using Flatseal.

If you want to take it a step further, I would recommend using Goldberg's Steam Emulator, which is FOSS, and it will allow you to bypass Steamworks DRM (which is Valve's very weak DRM) for games which solely use Steamworks DRM.

I find that the overwhelming majority of my games just use the Steamworks DRM if any, but YMMV. Using Goldberg's Steam Emulator is also a good way of preserving your library if, in the unfortunate case, Valve decides to remove a title from your library for whatever stupid licensing reason they come up with.

After freeing your games using Goldberg's Steam Emulator you then could use the Flatpak of Lutris and disable network access for Lutris/further restrict permissions it has to the rest of your system using Flatseal.

If I don’t alt-tab the game doesn’t break.

It's likely the 560 driver on Wayland being the culprit here. Specifically resizing XWayland windows. You could try running nvidia-smi in a terminal and see what specifically is causing this VRAM spike.

Reports of excessive VRAM usage with the 560 driver on Wayland. See this for a potential fix. Hope it helps

But if it is true, it may be more sensible to make an API so software with specific permissions could access information needed to effectively function as antivirus, without being run in kernel mode.

I've come to this conclusion as well. I believe Apple has similar functionality with their "kernel-extensions", I believe it's called.

I completely forgot about AI Anti-Cheat, lol. But yes, this is another form of Ant-Cheat that seems to be very effective. (Although I don't much like the idea)

You have a point, but if Microsoft completely locks down the kernel, preventing any third party software/driver from running at the kernel-level, Anti-Cheat developers will have to find a new way to implement Anti-Cheat. This may open up the possibility of some newer form of Anti-Cheat being user-space; or at the very least NOT ring 0, which in-turn may open up the possibility of this new form of Anti-Cheat working underneath Linux.

Or maybe we're all still screwed because this new form of Anti-Cheat will perform on a basis that trusts that there is no third party access to the Windows kernel because of how restricted it is, therefore nullifying the need to be ring 0, but it still might not work under Linux due to the freedom/access users have to the kernel.

But then again, in order to implement any third party driver into the Windows kernel, it has to be signed and/or approved by Microsoft first (IIRC). But cheaters get around this through various means. So maybe nothing changes; but if Microsoft DOES restrict kerne-level access, this leads me to think that Anti-Cheat will have to change in some form or another, which may lead to it working on Linux.

TBH, The only way(s) I see Anti-Cheat moving forward at all, is:

• Hardware level Anti-Cheat (similar to a DMA card. Maybe it requires a certain type firmware that is universally used across all/most major video game companies)

• Some form of emulated environment. Maybe like a specific kernel that is used for each game.

Why do certain security software require access to the kernel? To keep malware from getting to the kernel or something?

Security software doesn't necessarily NEED access to the kernel, but kernel-level access provides the maximum amount of access and visibility to the rest of the system. The only thing higher then kernel-level is hardware-level.

In the case of CrowdStrike, kernel-level access provides their software to have the highest privileges which yields in the most effective defense against malware (in theory). However third-party, kernel-level access is never a good idea. Software that has kernel-level access can be, and has been, exploited before. In the case of CrowdStrike, it was a faulty update that screwed over Windows systems. The more access you have in a system, the more you screw it over when something fails.

Doesn’t restricting access to the kernel offer more security?

Yes! You are correct. If implemented correctly of course, restricted access to the kernel provides a higher amount of security.

Wouldn’t malware also be unable to access the kernel?

In theory, the more restricted the kernel is, the more difficult it is for malware to access the kernel.

Kernel is what connects software and hardware, correct?

Yes. A function of the kernel is providing a way for software and hardware to communicate with each other.

In the meantime you can use this. Feel free to ask if you need further help.

Edit: I found this guide. Hope it helps!

Excluding hardware (microcode, UEFI, etc); within my Linux system, the only proprietary software I have installed are Nvidia drivers and Steam (installed via flatpak). When I first made the switch to Linux, I was actually shocked at the minimal amount of proprietary software I actually used/needed.

I was initially going to post just the changelog itself, but included in the changelog are other older fixes before July 22nd. Even though the fixes present on July 22nd are bolded, I decided to use the blog post because it only highlights the fixes for July 22nd. I didn't think of this previously, but I could have just posted the changelog, and specifically noted the July 22nd fixes 😅

Dr. Robotnik's Ring Racers

https://www.gamingonlinux.com/ is a wealth of information, of which, I am not willing to let go, as it is a resource of current news that is very relevant to this "Linux Gaming" sub. So no; I will not stop linking https://www.gamingonlinux.com/ to this sub just because you got butt hurt.

RIP our wallets 😓

Sorry for the trouble

No problem! I'm glad I could help :)

Do lutris always download user-made scripts, or is it just if you select it?

Lutris does not automatically download user-made scripts; you have to add them manually.

The only times I've encountered a game or program not launching via Bottles, it had to do with missing dependencies and/or other issues with the installer.

SteamDB has a list of dependencies that are used for Ape Out, of which you can try adding to your Bottle.

However, I would try running the game in Lutris; In Lutris, if you encounter issues with the game, you can click on "show logs" which will (hopefully) help you out a great deal. Lutris uses their own runtime which is primarily pulled from Valve's Steam runtime (IIRC), saving you from having to hunt for dependencies (if missing dependencies are the issue).

You can check if it's using the Discrete GPU by going into "Details" in your game's bottle, then go into "settings", and make sure that the toggle for "Discrete Graphics" is turned on. You can also set an environment variable; DRI_PRIME=1. Also might want to check your HDMI or DP cable is plugged into your GPU. You could also try checking GPU usage while the game is running, and seeing if it's using your GPU at all.

You said you moved to Fedora from Pop_OS; If you are using an Nvidia GPU, you might want to check if you've got the Nvidia Proprietary drivers installed or the Nouveau drivers. You can check this by running lsmod | grep nvidia in a terminal. If you get any output whatsoever then you're using the Nvidia Proprietary drivers, which is what you want for gaming.

If it is a shader issue; in the same "settings" in bottles make sure DXVK and VKD3D aren't disabled. There's no real way to bypass shader compiling. All your games need to compile shaders.

Happy to help!

It runs at 3–5 fps, and the CPU is maxed

Do you have a GPU or are you running the game on integrated graphics? Running on integrated graphics can definitely be the issue here but It's more likely that it's shader compilation however.

Assuming when you created the bottle, you chose "gaming", it will use "soda" as it's default runner, which is based off of proton. Maybe try going into preferences, runners, then click on "Soda", and try messing around with different versions.

According to the latest ProtonDB reports of Ape Out, Proton 8.0-5 was being used. Looking at my available "Soda" runners in bottles, I see soda-8.0-2,soda-9.0-1, and soda-experimental_8.0 as the latest runners available. I would try using those runners as a start.

Also, (I only now just noticed it), under preferences, in General, there is an "Integrations" section. Under that there's "Steam Proton Prefixes", which (I assume) allows you to use Proton prefixes.

Here are the following commands, depending on your installation method of Steam to give permissions to Steam's path if it doesn't have it already.

Steam non-Flatpak:

flatpak override --user com.usebottles.bottles --filesystem=xdg-data/Steam

Steam Flatpak:

flatpak override --user com.usebottles.bottles --filesystem=~/.var/app/com.valvesoftware.Steam/data/Steam

Alternatively you can use Flatseal and add the path: ~/.var/app/com.valvesoftware.Steam/data/Steam