I was trying to run Lethal Company and Deep Rock Galactic on my Linux computer using Proton, but I encountered some issues. On the ProtonDB website, both games were listed as running without problems. However, even after changing the Proton version or adding other launch options, nothing worked.

The solution I found was to uninstall both games from my secondary SSD (with larger storage, which I use for games, movies, and large files) and reinstall them on the primary SSD (where my OS is located).

I don’t want to use up space on my primary SSD (which doesn’t have much storage) to store Steam games. Is there a solution that would allow my games to work regardless of the SSD they’re installed on?

Note: the Steam and Proton files are installed on my secondary SSD.

After chatting with some people i just wondered if there are any keyboards or parts made only in the eu or made under fair conditions, bez i didn't found anything in this direction.

also i would appreciate if u propose keyboards having an linux compatibility out of the factory.

I bought a headset from AOAS that comes with two inputs; one for the headset and one for the microphone. However, when I connect it to my notebook (which only has one input for headsets), it works fine. However, when I switch the microphone from my notebook to the headset microphone, the headset audio stops working and only the microphone works. What could this be?

(I currently use Linux Mint, and I'll go back to just KDE neon when I buy a RAM memory. I've already tested it in live mode and it gave the same result.)

The headset works on my cell phone, and I already have an adapter so I can use the headset and microphone on the same input, but nothing is working, even with the adapter :(

Disclaimer: What I'm about to say could be very wrong. This idea sprang to my head a couple of days ago, and I could be misled by my own research. I'm posting this primarily as a way to be corrected/informed by people more knowledgeable than me.

The single biggest issue with Linux gaming is anti-cheat. While runtimes for Battle-Eye and Easy Anti-cheat do exist, they are fundamentally less secure. As much as people like to throw flack at devs for not enabling Linux support, what they fail to understand (or possibly ignore out of cope) is that allowing Wine/Proton players to run the game with kernel-space anti-cheat disabled, also allows cheaters to do the same by spoofing as a Linux client (irrelevant if they're actually using Linux or not).

So for good reason, those Proton anti-cheat runtimes are opt-in. So what's the solution? Well, to figure that out, we'll need to understand why KAC (kernel anti-cheat) is needed in the first place.

A game is a computer program, and a program's memory is isolated; another process cannot directly read/write the memory of another process. This done using "virtual memory". Instead of programs directly accessing physical RAM, the kernel abstracts memory space for each one.

But why doesn't this make cheating impossible? Because you can run cheats in kernel-space, bypassing this virtual memory isolation. A cheater could simply load a driver that manipulates the memory of a game, then all the anti-cheat can do now is memory obfuscation and other anti-tamper techniques; which results in the infamous "cat and mouse game" between cheaters and game devs.

We need a way to verify that the kernel has not loaded any cheating drivers. KAC does exactly this by also running as a driver, vetting other drivers that might be on a whitelist/blacklist of known safe drivers/cheats.

But, you can bypass this again by using a rootkit. If you load your cheats before the anti-cheat can load, the AC will have a much harder time detecting cheats. Thus, in this arms race of cheat vs anti-cheat, the anti-cheat also needs to run as a rootkit. And now we're at what we are today; anti-cheats like Vanguard that runs with full system access (scary!).

Now for my solution:

You may have heard of secure boot. It's a way of verifying if a booted image is approved by your computer's firmware (UEFI). It basically does this by check-summing your boot image, signing it, and enrolling it in a list of trusted hashes. Then, when you boot your system, it checksums the image you're booting and compares it against the enrolled hashes. This (if properly implemented) helps against OS tampering, but this only verifies the booted image to the UEFI, so this alone isn't sufficient as an anti-cheat measure.

TPM to the rescue! TPM (trust platform module) is a dedicated microprocessor for cryptography. It can generate and store key pairs to be used for encryption and signatures. Signatures specifically are important for what I'm proposing, since they're a way of verifying if a message is coming from a trusted source.

TPM has a feature called "Remote Attestation". This is similar to secure boot, as it's a way of verifying an OS, but the difference is that this can be used to verify the currently booted image by a third party (like a game server).

So how will this verification process work?

1. Secure boot and TPM needs to be enabled.
2. You must use a unified kernel image (UKI), since we want to verify the actual operating system kernel, and not a bootloader.
3. Said UKI's kernel sources need to be vetted by anti-cheat devs, and its binary checksum be added to an approval list. To be approved, a kernel should have no modules/patches that allows for cheating (duh), but also have any out-of-tree module loading support be disabled (dkms, akmod). All hardware support (cough, cough, nvidia, cough) must be compiled in.

With all said and done, only clients running specific kernels – such as the ones provided by a distro's repos – can be allowed to play games.

And guess what? It seems this process is already used by Riot Games' notorious Vanguard anti-cheat. It requires secure boot + TPM as a way of verifying that the booted OS hasn't been tampered with.

So why does Vanguard still need KAC? Because Windows NT is a microkernel; it needs to be able to load drivers out-of-tree for hardware support. Linux's advantage is that it's a monolithic kernel; all drivers can be compiled into the kernel image. That's why vetted kernels need dkms and akmod disabled.

If I haven't misunderstood anything about this whole process, this should be an effective way of curbing cheaters on the Linux platform. This is possibly even more effective on Linux than on Windows, due to Torvalds opting for a monolithic kernel design all those years back.

But as you may have already noticed, there are some downsides:

1. Your hardware needs to be supported by one of the vetted kernels, as you cannot load modules nor compile your own kernel.
2. No custom kernels; you won't be able to use kernel patches.
3. Your hardware needs TPM support. Luckily, this shouldn't affect most people.
4. As said before, you'll need to set up secure boot and use a unified kernel image.

Most of the issues above can be remedied by distro maintainers, and the Steam Deck specifically can likely set all this up via an OTA update.

So what do you guys think? Would you go through the effort of setting this up? Do you think distro maintainers, and more importantly, game devs will implement the following system just for us Linux gamers?

I hope so.

Hey buddies

I own an Asus x570 viii impact (the small m-dtx) version.

While the audio output is good enough for me on my MMX 330 Pro, the internal audio device is apparently not strong enough for the microphone (doesn’t work well on windows 10 either).

That’s why I am thinking about ordering an external USB DAC with headphone amplifier as a replacement.

My understanding is that the kernel already provides driver support for some DACs. But I’d like to ask for some first hand experience for you guys.

Is a creative sound blasterx g6 / x4 supported? I also think the GC7 “board” looks interesting. Or any other recommendation from your side?

Profile: gaming 90%, music 10% Relevant features: microphone amplifier, very good output

Using endeavorOS in case that’s relevant.

Cheers friends

Hello,

the scenario:

• main PC running Zorin (ubuntu/debian based)
• NAS running an SMB share (access as guest because I don't need Security in my home network)
• auto mounting the NAS drives via fstab

I tried for two days now getting steam to use my NAS for storage, but it always complains about no write permissions. Before that I got the issue of the drive not being executable (which I probably solved)

I hope someone here can point me towards the issue, because I don't see it anymore. From what I can tell, I do have full access to it. here is the fstab entry

//<ip-adress> /home/<myname>/fast cifs dir_mode=0777,file_mode=0777,exec,nocase,uid=<myname>,gid=<mygroup> 0 0

the mount works, I can access everything, can copy files, and all folders show as owned by me. Still steam fails downloading as soon as it tries to write anything. I really want to give Linux as a main OS a try, but it is always challenging me.. I also tried to make a new folder and copy in that, which also don't work.

On my NAS side, the new folder shows as owned by "Nobody" and "Nogroup", old folders show as owned by the user account of my NAS, but also with full write permissions for owner, group, and others.

Anyone an idea what else I can try?

https://youtu.be/hRpZnAhDMcY?si=EWNeAPrAe8-vsijE

With the recent accusations about Linux gamers cheating, please answer this curiosity poll about whether you've cheated on Linux.

View Poll