People on Twitter were trying to use those points to attack the new launcher and epic trying to give more attention to Linux

Source: https://x.com/GloriousEggroll/status/2110404004115272038

https://x.com/coral9000/status/2110443700522537193?s=20

People seem to think the new EAC is a magic bullet to solve all their problems while understanding little to nothing about how it actually works and what it means.

As I and many others have pointed out a kernel level anticheat in Linux starts with requiring the use of only pre-approved kernels and kernel modules, and here we are.

No, saying "just jump distros" is not a magic solution. Many people choose distros for very real very practical reasons.

Some might choose Arch spins for it's rolling release paradigm and up to date packagesband flexibility, while others might choose fodora for its corporate grade stability/predictability, while others might choose Debian for its bullet proof stability and security (unless you run change repos then you lose those).

Being told to jump distros by a gaming company of all things is a joke, and sets a very bad presidence. Many people left Windows to get away from a bunch of arbitrary requirements and now people are trying to welcome that concept into Linux.

There's also the issue of modules and out of tree drivers/kernel code.

Need a patch for a new NVME with a quirk? Sorry Tim sweeny didn't approve.

Want that driver for the new GPU that just dropped? Sorry gotta wait for a sweeny approved kernel before you can use it.

What about laptop modules? Users of Tuxedo and other brands use kernel modules to take care of managing board components and other things, now they can't play games unless they give up keyboard features and battery life?

What about BchacheFS users? Yeah it's a joke to be using an experimental file system but they want to, why does Tim get to say no?

What about Gentoo users? They just forgotten about? Just because I don't use it doesn't mean I'm going to condem them for no reason.

This doesn't just stop at anticheats either. The bigger issue is we have a platform where we own our computer and this is the start of the end of that. If everyone just bends over and accepts this then every company is going to start requiring kernel modules, tpm, and secure boot for everything and we'll be right back to a design we fled from.

All this can only happen if we accept it and the sad part is the immediate reaction from people who just swapped from windows recently seems to be " just surrender your PC so I can play a game bro!".

Kernel level AC hasn't stopped cheaters on Windows and now kids want us to install kernel level ACs onto our Linux machines just to still play against cheaters using windows?

I get people want to play their games but have some self control.

When the "solution" literally causes issues simply using your computer it's not a solution. If I wanted poor laptop support and waiting forever for GPU drivers I'd have chosen BSD.

I have no idea how the mere thought of fortnite makes people (some of which are grown ass adults) want to sabotage their own platform and be told what distros they can and can't use and what hardware they can and can't get full support for by a CEO who hates Linux.

We as a community shouldn't be settling for the worst possible option for game support.

If Blizzard can do a server side anticheat and still have the same if not fewer cheaters than fortnite then why is everyone so gung ho on slapping proprietary spyware in there machines for little to no gain?

I've seen quite a few people misunderstanding this announcement and claiming that Epic is bringing kernel-level anti-cheat drivers to Linux.

Epic explicitly confirms that EAC Linux v2 does not install or load a kernel module.

Instead, it uses existing Linux security features, eBPF programs and a systemd service that only runs while the game is running.

That doesn't mean it operates entirely in userspace, though. It still relies on kernel security mechanisms and requires things like Secure Boot, TPM 2.0 and signed kernels.

It's worth actually reading the technical details before assuming it's the same approach used on Windows.

Source: https://onlineservices.epicgames.com/news/introducing-easy-anti-cheat-linux-v2

Also epic is rebuilding Easy Anti-Cheat for Linux (EAC Linux v2) to deliver near-Windows-level protection using signed kernels, Secure Boot, TPM 2.0, and other existing Linux security features starting with a Fortnite, so more multiplayer games can finally support the platform without enabling widespread cheating.

https://onlineservices.epicgames.com/news/introducing-easy-anti-cheat-linux-v2

Download launcher here

https://launcher.epicgames.com/

From FAQ:

What should I know about Linux support?

The new Epic Games Launcher runs natively on Linux, but many games are Windows-only builds and may need a compatibility layer. Check each game’s Linux compatibility before installing.

We support Ubuntu 22.04 LTS or newer, Fedora 43 or newer, and Debian 12 or newer. Other distributions may work but aren’t officially tested or supported.

Use the Send feedback button in the launcher to report issues.

After reading the recent updates about the Epic Games Launcher and Fortnite coming to Linux, I could understand the reasoning behind things like enabling IOMMU, blocking kexec, and even the trusted kernels + modules signed with a known key. (I'm not a fan since I sign my own kernels and modules, but I digress)

Although, I saw lots of replies on Twitter about people complaining about the Secure Boot requirement. Why? Maybe I've just gotten too used to the command line, but doesn't sbctl handle the key creation and the signing of the contents in the ESP well? And, I thought most user friendly distros automatically setup Secure Boot nowadays?

Regardless of your intentions to play video games with anti-cheats, I'd say that securing the early boot chain is something everyone should do.

For context: Epic Games is reworking Easy Anti Cheat for Linux, for details read this: https://onlineservices.epicgames.com/news/introducing-easy-anti-cheat-linux-v2

This is IMO how Anti-Cheat should be handled, to best respect all parties involved (Gamers, game developers, regular PC users, ...)

On Windows, Anti Cheat has long been a race to the bottom (figuratively and literally). Cheaters try to undermine games, first with debuggers, then kernel modules, then DMA devices, ... while AC developers are fighting back with more and more invasive methods (rootkits, kernel drivers, always-on AC, ...). Regular gamers and users are the ones loosing heavily, as a single mistake this close to hardware has detrimental consequences. False bans because of wrong CPUs, accidental privilege escalations straight into the kernel, bricked hardware, ... are all possibilities.

Meanwhile on Linux, AC has long been very weak compared to Windows, as it runs exclusively in userspace. It couldn't do much more than asking the kernel nicely "please don't let other programs debug me". While great for the average user as this (obviously) isn't a rootkit, it makes cheating reasonably easy in comparison. This results in the average gamer encounters more cheaters, publishers not willing to port to Linux as a result, ...

The new Epic AC goes a new way: It uses a lot of tech (mostly spearheaded by systemd, Android and cloud / embedded environments) to ensure an "even playing field" where the core of the OS (hardware, firmware, bootloader, kernel) is trusted by all parties (users and games) to not contain any rootkits. All parts that are signed and "locked" by your distribution are easily auditable, by both Epic and you. On top of this, the regular userspace AC suffices to give the game very strong guarantees that nothing fishy is going on below, while also ensuring to users that they can still use their without having to trust Epic with their live savings, as all parties can mutually trust the same, open source code running below them.

I think this is an incredibly elegant way of handling AC, and is how it should've always been done (and has always been done outside of Windows, Android, iOS and most consoles use this "mutual trusted base" approach already, albeit not open source there.)

What do you think about Epics new AC?

Edit: Reading my post again, I want to make clear that I'm not shilling Epic in general. I really like how they are handling Easy AC v2, and it feels nice that Linux is being taken seriously by a company other than Valve, but I too have many issues with Epic.

I'm using Slackware Linux 15.0+ (current). I was able to install and run Caravan SandWitch easily, but the Store page shows nothing.

it's called My Beautiful Faraway, a short, surreal, melancholic walking sim inspired by older adventure games where you have to explore, pay attention to small details, and figure things out on your own without much guidance.

the gameplay is pretty simple: mostly walking around, talking to strange characters, and solving occasionally unconventional puzzles. a first playthrough takes around 3 hours, but there are multiple endings, optional content, and plenty of things you might miss.

the game is made in godot and has a native linux version, so there's no need for proton or any other compatibility layers. i also tried to make sure it works well with different hardware and controllers :)

steam page: https://store.steampowered.com/app/4516190/

The Oculus Rift S now runs natively on Linux SteamVR. No Windows, no Oculus software, no Meta account.

What works:

- Rock-solid headset and controller tracking, full 6DoF

- Room Setup inside the headset: floor and boundary, remembered between sessions

- Passthrough

- Controller haptics

- Your Linux desktop inside the SteamVR dashboard: open Steam, a browser or anything else without taking the headset off

- Settings app with a live view from the headset

- Plays normal SteamVR games: install, open Steam, click SteamVR

Install on Arch, no compiling:

curl -LO https://github.com/lbgos/rift-s-linux/releases/download/r28/rift-s-linux-bin-28-1-x86_64.pkg.tar.zst

sudo pacman -U rift-s-linux-bin-28-1-x86_64.pkg.tar.zst

Then reconnect the headset, open Steam and start SteamVR. AUR packages are coming once AUR registration reopens. Other distros can build from source.

Tested on Arch, KDE Plasma 6 Wayland, RTX 3090.

Source: https://github.com/lbgos/rift-s-linux

Free and open source. Bug reports welcome, especially from AMD GPUs and non-KDE desktops.

I first started using Linux with Mint, on a 2011 asus laptop, 8gb of ram, an hdd, a 2nd gen i7, and a 560M. It was terrible at the time to figure out what gpu flags to pass, I didn't have a big steam library, but Minecraft was punching 70fps on modern versions and playing what I consider heavy mods at about 30fps. It was nice, Windows it started at a baseline of about 30-40fps on modern, then modded was a no.

Then I got a desktop, 16gb ram, ryzen 5 3600, and an rtx 2060, and a solid state drive, that's all that's relevant for now. I grew out my steam library and got my most interesting test game, Satisfactory. Satisfactory includes a built in decent-enough hardware benchmark, and has potential to stress my cpu and gpu, and load times are noticable. With my desktop, I first started out on Windows 10 (So far 10 -> Mint -> 10) and found it alright, I couldn't customize though, and alt tab out of kerbal space program took ages, so I eventually switched to Linux Mint again.

On windows I could get about 100fps on modded Minecraft, around 300-400 with no mods, and Satisfactory benchmarked their "Medium" setting, and started lagging around Phase 3. Kerbal Space Program was not bench marked, but alt tab out of fullscreen took forever.

So, Mint, how does mint do? I tried Satisfactory on proton 9, because it's the top of the list. I was able to benchmark high settings, and my cpu was overall less stressed, and Satisfactory took less time to load. On top of that, Minecraft was now about 10-20fps better on modded, and able to push 700fps on no mods. Kerbal Space Program alt tab didn't take forever. Also got Portal 1 and 2 on here, which both ran 300fps, which is the limit, at max settings. Only issue was I had to change launch options to use proton after I got a 2nd and 3rd monitor. During this Mint stint I upgraded to 24, then 32, then 40gb of ram.

Eventually at some point I managed to completely break my display environment, and tried to switch to Windows 11. I had no time to benchmark games because I couldn't change my CRT res without a BSOD due to my amd gpu acting as a display adapter for vga and dvi-i. I had Windows 11 for about 3 hours tops, the whole time it was slow and clunky and had so many damn popups. No benchmarking time.

Then I swapped to Debian, same performance.

Then I had to pack the desktop, so I was back to the asus. Chucked an SSD in it, 20gb of ddr3, and tried Debian. I was getting about the performance I was getting before in Minecraft, Vulkan was still a no, but now I had more games to try. With the asus again I was able to get 120fps on Portal 2, dipping toward 90fps in some sections. No possible way to make satisfactory boot. It could also run KSP, but time was slower than realtime almost constantly in atmosphere, though in space it was fine, albiet my lap was warm.

Then I got the desktop back and tried Arch I finally realized proton experimental was a thing, and I was able to push a straighter fps graph on Satisfactory, nothing big yet. Meanwhile Minecraft didn't have noticeable gains, nor did other games. Biggest improvement was load times all being far lower than anything else I had tried, notably so.

However, I wanted to see if Cachy provided good improvements, I didn't expect much, but I was blown away. I tried cachy kernel and cachy proton. I boot into any game now and it feels like my mouse is attached to my movement, instead of the delay, it's like barely visible but highly sensible. Then I ran Satisfactory hardware benchmark. My 2060 is now doing ultra settings on an unreal engine 5 game at a very stable 60fps. Absolutely insane.

Across my journey of Win10 -> Mint -> Win10 -> Mint -> Win11 -> Debian -> Arch, one thing was constant, Linux surprising me about performance whatever I put it on, and feeling far more responsive. Other constant was Windows feeling like a prison. My DE journey is Win10 -> XFCE -> Cinnamon -> Win10 -> Cinnamon -> Win11 -> Gnome -> KDE -> (Laptop) KDE -> IceWM -> LQXT -> (Arch) XFCE -> I3wm. Overall happiest with IceWM but it has multimonitor issues.

Overall, I noticed a general trend on this subreddit of just posting things are broken, so I wanted to post my experience of everything working beautifully and swell, since nobody really posts about that?

The recent news is concerning. The more concerning issue however is that propel think this is only about Fornite, it's not. this is about every current and future ESC game

These are all the current Linux supported games, give or take, that users will lose access too after epic "sugests' they update to EAC Linux v2.

7 Days to Die

Armored Core VI: Fires of Rubicon

Back 4 Blood

BattleBit Remastered

Brawlhalla

Breachers

Caliber

Chivalry 2

Dead by Daylight

Deceive Inc.

Dragon Ball FighterZ

Dragon Ball Xenoverse 2

Dune: Awakening

Elden Ring

Enshrouded

Fall Guys

For Honor

Friends vs Friends

Goose Goose Duck

Guilty Gear -Strive-

Halo: The Master Chief Collection

Hell Let Loose

Insurgency: Sandstorm

iRacing

JoJo's Bizarre Adventure: All-Star Battle R

MotoGP 24

MultiVersus

Palworld

Phasmophobia

RIDE 5

Rust

S.T.A.L.K.E.R. 2: Heart of Chornobyl

Sea of Thieves

Sniper Elite 5

Squad

Starship Troopers: Extermination

The Division 2

The Isle

The Outlast Trials

V Rising

Warhammer 40,000: Space Marine 2

Warhammer: Vermintide 2

Watch Dogs 2

Then think about all the future games we won't have access to because EAC is easy and convenient for the developer. I guess we all better use only a few supported distros. oh wait.. 5 years for now it's only 1 supported distro that Microsoft just bought... oh well I guess this is good news...

i've made the swap back to linux (cachyos) a couple of months ago and never went back to windows. with that being said, i do have a 4070 ti and have been thinking recently if its worth the switch to an AMD card since its better compatibility and performance (from what i've heard). i know NVIDIA drivers have been improving throughout time with linux and is in a much better state then before but what do you guys think?

Funny things - the native EGS launcher on Linux does not tell you kind of compatibility layer it does use when running a game. It's a secret - it calls it "components". So far I tried Alan Wake 2 (it was a very picky title on the Linux some time ago) and it works just fine with all the Nvidia features enable. That said - everything is an enigma on the EGS - you cannot tinker in any way. Wonder how it works for other people brave enough to test it.

Hi everyone, I’m Jerzy from Clumsy Bear Studio, and after two and a half years of development we’ve finally launched our game, Hungry Horrors.

Hungry Horrors is a deckbuilding adventure through British and Irish folklore, cuisine and mythology, where you don’t fight monsters, you feed them. You play a spoilt princess who has no interest in being part of any adventure, but unfortunately your kingdom is swarmed by ravenous monsters. Every card played is a meal served, and each encounter is about keeping a Horror fed before it reaches you and feeds on you instead.

The game left Early Access and launched in full on Steam yesterday. It’s built entirely in Godot, with the art made in Aseprite. It has a native Linux build on Steam and it’s Steam Deck Verified.

• You don’t fight monsters, you feed them. It’s a spin on the deckbuilder formula built entirely around hunger, flavour cravings, and keeping a Horror satisfied
• Every dish is based on a real, traditional recipe from Britain and Ireland, many of which can still be found in pubs today, such as Stargazy Pie, Jellied Eels and Cullen Skink
• Every Horror comes from regional folklore, from well-known figures like the Dullahan, Jenny Greenteeth and Queen Mab to obscure local tales. The NPCs you meet along the way do too, including Herne the Hunter, the Wulver and Fear Gorta
• A story-driven roguelite Campaign and a punishing Banquet roguelike mode, so there’s a way to play whether you want narrative or quick replayability
• A deckbuilder driven by story, with quests, fishing, familiars, a skill tree and more
• Colourful 90s-inspired hand-pixelled pixel art and an original score, whimsical, creepy and cosy all at once

Steam: https://store.steampowered.com/app/3048840/Hungry_Horrors/

My mouse cursor leaves the monitor that fallout is running on, which makes it really hard to play the game if i ever want to turn left. There's an old post on this that i tried the solutions from, to no avail. I'm running Cachyos, using proton-cachyos-11.0 for my compatibility layer. I know it's possible to maybe attempt some kind of fix by tweaking .ini files but i'm not experienced enough to try that without some kind of guide. Any suggestions are appreciated. please, don't stay silent if you think i've tried it, because, once again, im not all that smart at this yet

GE-Proton11-8 Released

Repository: GloriousEggroll/proton-ge-custom · Tag: GE-Proton11-8 · Commit: c494a11 · Released by: GloriousEggroll

GE-Proton11-8

Changes since GE-Proton11-7.

Component Updates

• Updated Wine bleeding-edge, DXVK, VKD3D-Proton, VKD3D, D7VK, DXVK-NVAPI, DXVK-IGDext, FEX, lsteamclient, wineopenxr and protonfixes.
• Rebased the downstream patch stack and removed patches superseded upstream.

Controllers

• Added automatic PlayStation-to-XInput fallback when Steam Input is disabled, including appropriate controller identity and button origins for supported games. Native controller handling and real Steam Input take priority.
• Removed most (now obsolete) game-specific Sony fallback overrides; improved compatibility with Grandia I/ II, Lunar, Sky, God of War Ragnarok and Horizon Zero Dawn.
• Fixed Diablo IV's startup DualSense detection and added DualSense Edge compatibility.
• Fixed Castlevania Anniversary Collection controller replacement and late connection.
• Improved DS4 speaker audio, Sony controller hotplugging, Death Stranding speaker switching and Monster Hunter Wilds haptics. Addressed audio initialization races and expensive controller polling.
• Added Switch Pro/compatible controller XInput support and corrected Dynasty Warriors 8 DualSense mappings.

Steam Overlay

• Fixed Guide-button overlay not closing under Wine-Wayland, including Labwc and Warframe.
• Improved overlay cursor ownership and visibility; fixed a Wine-Wayland clipboard-related World of Warcraft crash.

Wayland and Windowing

• Fixed fullscreen Alt+Tab restoration in Guild Wars Reforged
• Fixed startup/minimize recovery for Deadlock on Niri. Added cross-driver suppression of the transient minimized-window white rectangle. (#781, [#762] (#762))
• Improved Battle.net tray-menu rendering, positioning, keyboard focus, cursor handling and tray recovery.
• Fixed Warframe's missing launcher settings dialog and disappearing cursor.
• Fixed Touhou 11's unwanted fixed-window resizing
• Fixed Zenless Zone Zero launcher window being mistaken for a tray menu.
• Improved GNOME direct-scanout compatibility, Vulkan surface opacity metadata and cursor confinement updates.
• Preserved Assassin's Creed DX10 fullscreen mode across Alt+Tab.

Video Playback

• Improved VRChat YouTube, HTTP MP4, HLS, MPEG-TS and RTSP playback, including URL compatibility, playlists, seeking, pause/resume, audio synchronization and periodic streaming stalls.
• Enabled AV1 decoding through dav1d.
• Fixed Resident Evil 4 video corruption and improved intro playback performance
• Fixed WUCHANG skill-preview videos. ([#775](https://github.com/GloriousEggroll/proton-ge-custom/ issues/775), #787)
• Added playback fixes for Borderlands 3, Saku Saku, Fairy Fencer F Advent Dark Force, SHUFFLE! Essence+, Hatsumira, Colin McRae Rally 3 and One Piece: Pirate Warriors 4.
• Fixed interrupted music in T4C Neerya and an audio-sample memory leak affecting Apple Jack.
• Fixed Way of the Samurai 4 movie-skipping crashes.
• Improved King of Fighters XIII and Taito Type X2 movie compatibility, added DirectDraw video-overlay emulation, and fixed a seeking deadlock affecting SNK Heroines.

Rendering and HDR

• Added reported-working StarCraft II GPU-hang workaround. ([#790](https://github.com/ /issues/790))
• Fixed Meridian: New World's dark lighting and scrolling flicker through Wine-Mono/FNA stencil-state fixes.
• Fixed Le Mans Ultimate initialization and HUD/text rendering through Direct2D improvements. (#777)
• Enabled Warframe's DX11 HDR detection and added SDR fallback when HDR is requested but unavailable on the output.

Protonfixes

• Project Torque: corrected .NET dependencies and disabled Xalia to prevent startup problems.
• The Witcher 3: hid Wine exports to restore graphics features disabled by the game's Wine detection.
• Added or updated fixes for A Way Out, Way of the Samurai 4, Ceville, Kanvas Launcher and the original Call of Duty's non-Steam release.
• Updated the UMU database and fixed the unzip dependency URL.

Other Changes

• Added opt-in Bluetooth LE support for applications such as Zwift and Rouvy using PROTON_ENABLE_WINEBTH=1.
• Fixed unsafe timing-source selection, process-exit hangs, Richard Burns Rally's exit crash, and serial-port probing that disrupted Sinden lightguns.
• Added SHA-256 certificate-property support for MTA and corrected incomplete TLS-record handling.
• Restored ARM64 DXVK-NVAPI builds, enabled FEX disk caching by default, and updated upstream game/launcher compatibility fixes.
• Expanded controller documentation and replaced obsolete RDNA3-specific FSR4 guidance with PROTON_FSR4_UPGRADE.

I run Steam in TTY using gamescope (Makeshift SteamOS gaming mode). I mainly did that because I found it can give less RAM consumption, even though it doesn't really matter on 16GB RAM.

This is the command line I use: "STEAM_GAMESCOPE_VRR_SUPPORTED=1 STEAM_MULTIPLE_XWAYLANDS=1 gamescope --mangoapp -W 1920 -H 1080 -r 165 -O DP-1 -e --xwayland-count 2 -- steam -steamdeck -steamos3"

Though I was thinking, are there some parts of the command I do not need and things would still work the way I want them too? I'm a bit afraid to do that because I had an issue where the mouse wouldn't move the camera in TF2, and I have no idea what parameter it is that fixes the issue.

Someone give me good Terminal games

So many people have been begging for big live service games to come to Linux, and I think this anti cheat method is exactly the way I expected this technology to go, a set of approved kernels that the developer can trust to make sure nothing is being tampered with. I think this is a good compromise for most of us who just install the main line Linux kernel on mainstream distros.

Unfortunately I think server side anti cheat is a lost cause. Not only will game developers not entertain the idea one bit, but for a lot of gamers, anti cheat is something they want to know about. For heaven's sake, EA advertised their Javelin Anti Cheat in Battlefield 6's marketing, Call of Duty put a big fat Ricochet Anti Cheat logo when booting up the game. Companies want you to know what anti cheat is used with what, and hope you will have a cheat free experience. As long as there is a jerk out there who is using every means and dollar necessary to get an advantage over someone, because humanity can suck some times, anti cheat is going to be a thing, and the industry chose its method. It has been known that despite cheaters mostly running Windows, Linux technology is being used to cheat in games regardless through spoofing Wine prefixes and other wacky methods. Some Linux cheats are open source! Cheating is easier on Linux, a more secure and trusted way of doing things had to happen, full stop.

Epic's method seems to rely on technology being used in the cybersecurity space on Unix to detect cheaters using the latest and greatest in security. Using systemd, IOMMU, and eBPF, all of which are in the Linux Kernel already makes sure we don't have to do much to make sure the anti cheat works. In fact, Embark Studios is looking into a similar method for their anti cheat, and they are well liked in the Linux community. I can see how this can be a way going forward for those of us who want to play big cheating vulnerable games on their Linux systems. Does it reduce choice, yes, but given we can just boot into another kernel in GRUB or another boot loader for everything else, I think its a good compromise, and plus, we can just not play these anti cheat games if we don't want to deal with it.

As far as my setup is concerned, I have been using Fedora and now RHEL 9 for my Linux usage and have enabled both secure boot and TPM on my system, however on my current RHEL 9 system I use the CachyOS Kernel for more hardware support and NTSYNC for certain games, and both installs use Nvidia drivers from negativo17.org, so I had to sign these drivers and the CachyOS kernel on RHEL for secure boot. I am not sure if my set up will work with this new method Epic is planning. Secure Boot can be a pain if you don't know what you are doing, but I have always defaulted to using it so my Windows drive can boot and I can play Call of Duty on it which requires an up to date bios and secure boot. The big question is that I have not seen Epic Games say anything about Nvidia dkms or akmods so far. They must know that both RHEL and Fedora and many other distros do not ship Nvidia drivers in their kernel and require things like RPM Fusion or Nvidia' official DKMS drivers form their repository to get these things running. I hope Epic can be more clear about this, as they are in bed with Nvidia's technology for the Unreal Engine, an Nvidia first thing. Again, with GRUB and other boot loaders allowing you to use different kernels upon boot, I think we will have an option to just install the Epic approved kernel to play a handful of games, and then your super optimized custom kernel for whatever the heck you want next.

Either way if this anti cheat method works I wonder if Activision, Riot or others will begin to adopt this method for anti cheat. Epic has said that they are reaching out to distro maintainers and developers to make sure their kernels work with EACv2, so maybe things like the CachyOS Kernel and others will get proper support. Maybe one day we will get an open source framework for a Linux anti cheat that can be shipped with the Linux kernel, but I am not technical enough to even comprehend how that can go about.

I hope I didn't sound like a blithering idiot, but I am cautiously optimistic about this new approach to anti cheat. Now we need to get the modern CODs working on Linux, and I will be happy, but until then I will keep playing Plutonium Black Ops 2 on my CachyOS Kernel on RHEL 9 with Nvidia drivers.