Steam On Linux Use Ticked Higher In May, 25% Of Linux Gamers Are Using The Steam Deck

[drakonas777]

Competitive multiplayer is not "the thing" in Steam Deck community AFAIK. Also, Valve people can always rework security mechanisms if they choose to do so. This anti-cheat discourse is an ordinary meltdown of birdie/avem/avis, because SD is AMD SoC based device with Linux inside and open source community likes it. Ergo, birdie/avem/avis must come to comments, write provocative bullshit and complain about FOSS "toxicity" afterwards.

[oiaohm]

"There are many cheat hypervisors" - I'll stop you right there. Many implies at the very least five, ok four.

VAC documents at last count 14000 hypervisors they have to check for that cheaters have made all have windows claiming secureboot is enabled. Cheat developers are very active people.

Go ahead and list four well known and widely used Windows cheats which work as hypervisors.

There are wide enough used

Secondly, how many of them do provide Secure Boot environment?

The reality all cheater made hypervisors these days provide fake secureboot some provide fake TPM.

Again, Windows at least has some defenses against cheaters and low level malware, Linux has basically none and is open to hacking of anything and everything, yet we have now two people in this discussion who claim that Windows protections are worthless. They are not. I trust my Windows 10 installation a lot more than I trust my Linux install. In Windows I know what I run, almost every executable file on my system has a digital signature, in Linux I've no idea what I run. The kernel and its modules are signed. Great. That's it. Even the initrd may contain malware, I'll never be able to discover. And that's Fedora.

Can you run scripts early in the windows startup process that can undermine you system in the same way initrd can on Linux. The answer is yes and different cheat and malware developers do exploit this under windows.

https://github.com/secretsquirrel/SigThief

Are you sure they are valid signatures. I love secret squirrel work in this department. Turns out that you can take valid signature from one application put it on another one and Windows can be perfectly happy. Windows executable signing is proven false security.

The reality avis you should be trusting windows and Linux equally because the so called extra security of windows has failed testing by people who decided to test it.

[oiaohm]

Wine DLLs being implemented as Windows compatible PE modules does not make Win32 API native to Linux. libwine.so still translates Win32 API to POSIX API. A ton of Win32 API calls have no equivalents in Linux and vice versa. libwine cannot possibly become a Windows application, as the Linux kernel has no idea how to execute PE (portable executable) files. There's so much complete baloney in your post, I'm just speechless.

There is a catch here. Dynamic ELF linux kernel really does not know that much about. Linux kernel knows enough that it sees dynamic elf finds the static elf loader entry and then runs that. The reality is Linux kernel has no idea about dynamic elf files either. So Linux kernel having no idea about PE and PE be a dynamic binary format equals basically status normal for the Linux kernel.

The reality is you don't use native Linux kernel loaded binaries on Linux 99% of the time.

Lots of the Win32 API has no equivalents in Windows syscalls. Windows is designed to abstract access to the system by .dll files. There are particular windows dll like ntdll.dll that cannot be swapped between windows versions.

Sorry ruin your day but libwine exists on windows. There are some games that are old that have libwine.dll built from wine source for windows because the game is 16 bit and they are using emulation to run on windows. libwine in wine is not just for win32 to posix but is also used in win16 to win32. So libwine cannot possible become windows application is false the win16 to win32 parts libwine absolute can be built for windows winevdm and others do. libwine is not black and white here it shades of grey parts of it build for windows.

[avis]

https://github.com/SamuelTulach/SecureFakePkg

Sorry secureboot/TPM does not help. There are many cheat hypervisors The reality is "Secure Boot/TPM/signed Windows kernel driver to have the assurance that the system is not compromised" does not in fact mean anything because you are cheat makers breach that at the Secureboot/TPM level.

Yes boot with secureboot off load a module that software provides TPM and tells windows that secureboot is on and windows believes it. So hacked from firmware. This hacked from firmware allows booting windows in test signing mode then after cheat driver is loaded switching displayed to applications flags that signing is on. The reality by the time the game loads the cheat is hidden.

Anti-cheat systems cannot depend on Secureboot or TPM or windows driver signing as all of those are defeated. Linux in a lot of ways is more truthful about what is secure.

"There are many cheat hypervisors" - I'll stop you right there. Many implies at the very least five, ok four. Go ahead and list four well known and widely used Windows cheats which work as hypervisors. Secondly, how many of them do provide Secure Boot environment? I love facts, oiaohm. For the past 24 hours at least a dozen of Linux fans have tried to feed me with BS. I've eaten more than enough. Thank you. I need solid facts, proofs, citations. "Many" as you said.

Again, Windows at least has some defenses against cheaters and low level malware, Linux has basically none and is open to hacking of anything and everything, yet we have now two people in this discussion who claim that Windows protections are worthless. They are not. I trust my Windows 10 installation a lot more than I trust my Linux install. In Windows I know what I run, almost every executable file on my system has a digital signature, in Linux I've no idea what I run. The kernel and its modules are signed. Great. That's it. Even the initrd may contain malware, I'll never be able to discover. And that's Fedora.

Many people here have Secure Boot completely disabled because their favourite disto doesn't support Secure Boot.

[oiaohm]

Linux cannot even provide a secure base platform for games to rely on. In Windows games which want to protect you from cheaters may use Secure Boot/TPM/signed Windows kernel driver to have the assurance that the system is not compromised and you're not running cheat applications. In Linux, nothing is guaranteed. Linux fully trusts custom MOK certificates, so even Secure Boot is a joke in terms of providing system integrity..

https://github.com/SamuelTulach/SecureFakePkg

Sorry secureboot/TPM does not help. There are many cheat hypervisors The reality is "Secure Boot/TPM/signed Windows kernel driver to have the assurance that the system is not compromised" does not in fact mean anything because you are cheat makers breach that at the Secureboot/TPM level.

Yes boot with secureboot off load a module that software provides TPM and tells windows that secureboot is on and windows believes it. So hacked from firmware. This hacked from firmware allows booting windows in test signing mode then after cheat driver is loaded switching displayed to applications flags that signing is on. The reality by the time the game loads the cheat is hidden.

Anti-cheat systems cannot depend on Secureboot or TPM or windows driver signing as all of those are defeated. Linux in a lot of ways is more truthful about what is secure.

[mrg666]

I was busy exterminating a bunch of Tyger Claws. Cyberpunk is working flawless at 4K with Plasma 5.27.5 Wayland, Linux 6.3.5 (custom), Mesa 23.1.1, latest experimental Proton, RX 6800 XT and i7 13700K @6GHz. This is a dream came true after so many years thanks to so many developers, especially Wine, Linux, Steam, AMD, Mesa, and others.

[avis]

Is DirectDraw native API on Windows? Is it or not?

It's completely implemented on top of newer Direct3D nowadays so it's "pure emulation" in your mind, even on Windows.

What DirectDraw? What does DirectDraw have to do anything with our discussion for Christ's sake? It's an old API for 2D graphics in Windows. Games rarely if ever used it. The API has effectively been dead for ages, for almost two decades now. Why did you even bring it to this discussion?

Wine DLLs being implemented as Windows compatible PE modules does not make Win32 API native to Linux. libwine.so still translates Win32 API to POSIX API. A ton of Win32 API calls have no equivalents in Linux and vice versa. libwine cannot possibly become a Windows application, as the Linux kernel has no idea how to execute PE (portable executable) files. There's so much complete baloney in your post, I'm just speechless.

I will not argue with any further as I value my sanity a lot more than trying to right the wrong-thinking of others. I've done this before - it doesn't work.

"DirectX under Windows is/uses emulation, Proton is better". I'm out. This is madness.

Have a nice day.

[Weasel]

First, is Win32 native API to Linux? Is DirectX native API to Linux? You may build a hundred layers of excuses and tricks to claim that's not "emulation" only I don't give a damn about rich verbiage. These are completely alien APIs and they will never work as well as they work under an OS which provides them natively. It's a ton worse than what FreeBSD does. FreeBSD's Linux emulation is actually very close to running natively.

Is DirectDraw native API on Windows? Is it or not?

It's completely implemented on top of newer Direct3D nowadays so it's "pure emulation" in your mind, even on Windows. This is why your logic is a farce.

You can use DXVK on Windows, to show you that it's not any less native than Windows, it still translates DX11 API into Vulkan calls. That's still native.

Most of Wine code is pure PE (EXE/DLL) files with no calls to the unix libraries, other than the few low level ones. Such code will work on Windows as well in most cases if you replace the system dll. It's as "native" as it gets, because it implements the same shit, purely in userspace.

Why the fuck would an API that, say, generates some random numbers be different and less native on Linux simply because you say so? The implementation is no different that Windows (well it might be slightly different, but the contract is the same, I mean it's not like it's reverse engineered, it's built from scratch based on the API contract).

Second, Windows Test Mode is easily discoverable. Of course as a cheat author you can hide everything but the user will have to enable testsinging mode in the first place and many will not do because they will be scared. That's too close to actually running malware on your system.

Third, under Linux there's zero guarantee that anything that the game works with is real/pristine. The kernel driver, Mesa, everything can be replaced/patched however the user wants. In Windows the entire system is digitally signed starting from the bootloader. Overriding this is extremely difficult if not impossible. And let me tell you one thing: there are undetectable hardware cheats. The problem is they are all bespoke and not produced on a mass scale. I'm fine with all the 20 people in the world who have them. I'm not fine with practically any Linux user who can be a dirty cheater because there's no way to verify their system integrity.

As I said you can use a custom driver to bypass that, since it runs in ring 0.

You say it's close to running malware. You're a cheater in this case, do you care? Heck 99% of users don't give a shit about signed binaries in the first place.

You know what else is close to running malware? Your stupid anti-cheats that hook into drivers or install drivers. Bypassing them usually is less malware and intrusive than not.

God, the amount of weaseling out, just to misrepresent how horribly bad Linux for Windows gaming is, is just disgusting.

I'm totally fine with Wine, DXVK, proton, whatever. This is not "Linux gaming" and never will be. Maybe start with the English language and basic logic.

Let's call this DXVK/Wine gaming under Linux because outside this combo, there's nothing to speak of. Not a single native AAA title for Linux for the past five years. Or maybe there have been one or two. Well, Windows has at least five dozen of them annually.

You're gaming on Linux, so it's Linux gaming.

I don't give a shit about native titles. In fact, unless performance is a problem, I'd prefer Proton simply because you have more control over it and devs don't have to build a "Linux version" (yes, I do care about devs' time as well).

What do I mean by more control? Imagine a title comes up that only supports X Linux API or library (say, PulseAudio), or supports only Wayland (yuck) or only X11 (better). What do you do then if you want to run it on another driver or display server? You need a compatibility library. What if there isn't one? You're fucked.

Enter Proton. Proton is that compatibility library, since it exposes the Windows-equivalent API, which is then translated at some point to whatever driver you're using.

In 20 years, a new driver might be written for Wine to deal with a new Linux driver or display server or system. Guess what? The game doesn't give a shit cause it still interfaces with the Windows API. It doesn't know it's running on PulseAudio under-the-hood, nor does it need to.

It's no fucking different than old, deprecated Windows APIs, which are entirely implemented on new, modern Windows APIs, even on Windows.

So Proton > native unless its performance is bad. Deal with it.

[Tuxee]

yeah right... you are in favor of buy windows devices thats why you do not want steamOS devices in the market.

Neither my laptops (Thinkpad X13 and previously an HP Elitebook) nor my desktops (all of them) came with Windows.

[Quackdoc]

Tried using holoISO on arc a380 in a qemu VM, sadly didnt work, tried emulating steamOS on arch by launching steam's gamepad UI on gamescope via DRM, sadly doesnt work either just launched the game and shows a black screen, audio still plays the overlay flashes when you try to open it up? wondering if this is yet another polaris issue.