EAC v2 and Fortnite coming to Linux

[erek]

... and sure enough, here we are. Here's the kernel with support and instructions.

https://github.com/CachyOS/linux-cachyos/pull/1084

https://github.com/CachyOS/wiki/pull/650

Commentary,

"CachyOS Announces EAC Linux V2-Compatible Kernel With Lockdown​

by Cpt.Jank Today, 19:15 Discuss (0 Comments)
Epic Games recently promised expanded Linux support for Easy Anti-Cheat, outlining a new set of standards and native Linux security features that would need to be adopted by Linux distribution developers who wanted gamers to be able to access EAC Linux v2 games. As is par for the course for the distribution, CachyOS has come out swinging as one of the first, if not the first, Linux distribution to explicitly announce support for EAC Linux v2.

The announcement comes by way of a discussion on CachyOS's GitHub. Although its developers have yet to fully implement the new features, CachyOS's maintainers and developers are quick to note that the linux-cachyos-eac kernel will be a fully optional feature for the desktop environment, and that it will be opt-in. That's an important point, because some of the features required for EAC Linux v2 have been quite controversial in Linux gaming circles."

 

[Mazzspeed]

Commentary,

"CachyOS Announces EAC Linux V2-Compatible Kernel With Lockdown​

by Cpt.Jank Today, 19:15 Discuss (0 Comments)
Epic Games recently promised expanded Linux support for Easy Anti-Cheat, outlining a new set of standards and native Linux security features that would need to be adopted by Linux distribution developers who wanted gamers to be able to access EAC Linux v2 games. As is par for the course for the distribution, CachyOS has come out swinging as one of the first, if not the first, Linux distribution to explicitly announce support for EAC Linux v2.

The announcement comes by way of a discussion on CachyOS's GitHub. Although its developers have yet to fully implement the new features, CachyOS's maintainers and developers are quick to note that the linux-cachyos-eac kernel will be a fully optional feature for the desktop environment, and that it will be opt-in. That's an important point, because some of the features required for EAC Linux v2 have been quite controversial in Linux gaming circles."

There's no "lockdown" involved. EAC v2 compatible means it's a signed kernel, that's it.

 

[DukenukemX]

I don't plan to play Fortnite so I won't be installing that kernel, but at least it's nice to know it's there.

 

[Mazzspeed]

I don't plan to play Fortnite so I won't be installing that kernel, but at least it's nice to know it's there.

Exactly. I'm gonna try it because I'm curious.

If you don't run custom kernels, you could run the signed kernel with secure boot disabled just as you do now under the default Cachy kernel and nothing will change.

 

[ChadD]

Exactly. I'm gonna try it because I'm curious.

If you don't run custom kernels, you could run the signed kernel with secure boot disabled just as you do now under the default Cachy kernel and nothing will change.

We'll have to see what epic allows and what they don't. I would expect all the stuff that makes the cachy kernel the cachy kernel will be stripped out. I doubt things like ZFS support (not that i use that just an example) are going to not be in the eac kernel. (and yes I like my custom kernel... not being able to compile your own kernel is not something worth agreeing to.. imo anyway)
I get it its just an option. I think at this point no one really knows what Epic is ok with. We are being asked to surrender a lot of control of our systems for anti cheat. Anyway you know my take. For what its worth I would like to be wrong. It sounds great in theory. A stripped down kernel we can all keep handy for that handful of cheaty shooters that won't run on free Linux. It sounds great. Hey a lot of the Linux world has put a lot of faith into eBPF. Its great tech and a good solution for network traffic filtering at scale and all the things Meta Google Netflix and the like have been using it for. Is it going to be cheat maker proof? We'll see. If Vavle does end up being on board with this and it goes forward. I'm sure this time next year we'll be debating Epics move to EAC2.5 requiring the use of CPU hardware features like AMD SEV-SNP or Intel TDX next. The hamster wheel is going to have to keep turning once we step onto it.

 

[uOpt]

That's just way beyond acceptable.

 

[Mazzspeed]

We'll have to see what epic allows and what they don't. I would expect all the stuff that makes the cachy kernel the cachy kernel will be stripped out. I doubt things like ZFS support (not that i use that just an example) are going to not be in the eac kernel. (and yes I like my custom kernel... not being able to compile your own kernel is not something worth agreeing to.. imo anyway)
I get it its just an option. I think at this point no one really knows what Epic is ok with. We are being asked to surrender a lot of control of our systems for anti cheat. Anyway you know my take. For what its worth I would like to be wrong. It sounds great in theory. A stripped down kernel we can all keep handy for that handful of cheaty shooters that won't run on free Linux. It sounds great. Hey a lot of the Linux world has put a lot of faith into eBPF. Its great tech and a good solution for network traffic filtering at scale and all the things Meta Google Netflix and the like have been using it for. Is it going to be cheat maker proof? We'll see. If Vavle does end up being on board with this and it goes forward. I'm sure this time next year we'll be debating Epics move to EAC2.5 requiring the use of CPU hardware features like AMD SEV-SNP or Intel TDX next. The hamster wheel is going to have to keep turning once we step onto it.

There is no reason whatsoever why the kernel used won't be identical to the default CachyOS kernel, the only requirement is that the kernel be signed using a well known key. The conspiracy theories are getting pretty intense here Chad. Personally, I don't even see a reason to have a separate signed kernel to use with EAC, just sign the default kernel and be done with it. I believe the only reason why the lead dev of CachyOS is providing an alternate signed kernel for use with EAC v2 is because he knows that people swayed by those slinging conspiracy theories would loose their minds over "locked down kernels" being the default.

Once again, this is nothing more than a signed kernel.

 

[ChadD]

There is no reason whatsoever why the kernel used won't be identical to the default CachyOS kernel, the only requirement is that the kernel be signed using a well known key. The conspiracy theories are getting pretty intense here Chad. Personally, I don't even see a reason to have a separate signed kernel to use with EAC, just sign the default kernel and be done with it. I believe the only reason why the lead dev of CachyOS is providing an alternate signed kernel for use with EAC v2 is because he knows that people swayed by those slinging conspiracy theories would loose their minds over "locked down kernels" being the default.

Once again, this is nothing more than a signed kernel.

It will be... things like Sched-ext are out. Their are other restrictions as well.
https://github.com/CachyOS/linux-cachyos/pull/1084

Again we'll see where this goes Maz. Good on Peter for engaging with Epic. This is still looking like a whole bunch of bs to me. Still haven't heard from our friends at Valve have we?

https://github.com/CachyOS/wiki/pull/650
- Limine stays your default boot manager. The CachyOS-signed systemd-boot is installed next to it, in its own
- This feels like a messy workaround. You have to maintain two sets of pacman hooks, and you still have to reboot your OS just to play games with EAC :/
ptr1337 19 hours ago
Yes, but there is no other way. Limine doesnt work, but the majority of our userbase is on Limine therefore we need to find a way properly supported.

As Peter works to implement this Maz, it looks more and more like a huge massive PITA. Maybe things smooth out as this progresses.

 

[Mazzspeed]

It will be... things like Sched-ext are out. Their are other restrictions as well.
https://github.com/CachyOS/linux-cachyos/pull/1084

Again we'll see where this goes Maz. Good on Peter for engaging with Epic. This is still looking like a whole bunch of bs to me. Still haven't heard from our friends at Valve have we?

https://github.com/CachyOS/wiki/pull/650
- Limine stays your default boot manager. The CachyOS-signed systemd-boot is installed next to it, in its own
- This feels like a messy workaround. You have to maintain two sets of pacman hooks, and you still have to reboot your OS just to play games with EAC :/
ptr1337 19 hours ago
Yes, but there is no other way. Limine doesnt work, but the majority of our userbase is on Limine therefore we need to find a way properly supported.

As Peter works to implement this Maz, it looks more and more like a huge massive PITA. Maybe things smooth out as this progresses.

Based on my testing comparing CachyOS performance to KDE Neon running a variety of schedulers, the difference in performance is minimal to none. In fact, under some titles KDE Neon is a hair faster on the same hardware no matter what the scheduler under CachyOS, and you have none of the disadvantages that come with changing schedulers for something intended for gaming. In many cases, any perceived performance improvement is within the margin of error. Personally I gave up on alternate schedulers not long after installing CachyOS, but if you still want to run different schedulers you have options, so you're loosing nothing in letting others have options that are likely more suited to their use case.

Personally, I think Limine's ugly and I use Grub on all my systems, including my CachyOS system (and yes, btrfs snapshots work fine under Grub). However there is a workaround for Limine and apparently it works, the implementation can't be any more ugly than Limine's UI.

The rest of it seems to be scripts to enable eBPF, enable IOMMU support, disable Kexec, and enable kernel lockdown integrity mode - that way you can swap kernels and settings are applied/removed automatically. Personally, I've been running KDE Neon with such functionality enabled for weeks now with no compatibility issues or problems whatsoever - in fact I like the increased security. Basically, under CachyOS you have a button that "Enables EAC v2 Mode" - Which loads an identical kernel to the one you're using now with the exception it's signed and enables/disables certain features via scripts as required by EAC v2 (however, the kernel itself is identical). Which may actually drive EAC v2 adoption somewhat, as I've had to manually enable such features and there was some nutting out/work involved in doing so.

I wouldn't be at all surprised if most users end up enabling this mode and just leaving it enabled once all the paranoia settles down. It's like certain political spectrum's complaining about Government spending re: infrastructure, once the infrastructure's built the complaining stops and those particular spectrum's tell everyone how useful it is. But I digress...

As for Valve, as I've stated at least twice now, give it time. Steam Deck adoption will not stop EAC v2, if Valve don't want to negotiate and provide support for features that should already be supported, than the SteamDeck doesn't support Fortnite - I can assure you should that be the case, SteamDeck users will turn on Valve in a heartbeat.

But such a scenario is somewhat unlikely, I see no reason whatsoever why Valve wouldn't be haggling out the specifics as we argue semantics over what might happen. I'm not interested in the elusive crystal ball, I intend to remain open minded and reserve judgement for when EAC v2 is released and the expected teething issues are sorted out.

 

[CrimsonKnight13]

Limine ugly? It can be styled with themes & wallpaper.

 

[Mazzspeed]

Limine ugly? It can be styled with themes & wallpaper.

You can style Grub with themes and wallpaper, it still looks better than Limine even with themes applied to both. I honestly never understood just why Cachy devs pushed Limine over Grub when both are equally capable bootloaders.

 

[ChadD]

Based on my testing comparing CachyOS performance to KDE Neon running a variety of schedulers, the difference in performance is minimal to none. In fact, under some titles KDE Neon is a hair faster on the same hardware no matter what the scheduler under CachyOS, and you have none of the disadvantages that come with changing schedulers for something intended for gaming. In many cases, any perceived performance improvement is within the margin of error. Personally I gave up on alternate schedulers not long after installing CachyOS, but if you still want to run different schedulers you have options, so you're loosing nothing in letting others have options that are likely more suited to their use case.

Personally, I think Limine's ugly and I use Grub on all my systems, including my CachyOS system (and yes, btrfs snapshots work fine under Grub). However there is a workaround for Limine and apparently it works, the implementation can't be any more ugly than Limine's UI.

The rest of it seems to be scripts to enable eBPF, enable IOMMU support, disable Kexec, and enable kernel lockdown integrity mode - that way you can swap kernels and settings are applied/removed automatically. Personally, I've been running KDE Neon with such functionality enabled for weeks now with no compatibility issues or problems whatsoever - in fact I like the increased security. Basically, under CachyOS you have a button that "Enables EAC v2 Mode" - Which loads an identical kernel to the one you're using now with the exception it's signed and enables/disables certain features via scripts as required by EAC v2. Which may actually drive EAC v2 adoption somewhat, as I've had to manually enable such features and there was some nutting out/work involved in doing so.

I wouldn't be at all surprised if most users end up enabling this mode and just leaving it enabled once all the paranoia settles down. It's like certain political spectrum's complaining about Government spending re: infrastructure, once the infrastructure's built the complaining stops and those particular spectrum's tell everyone how useful it is. But I digress...

As for Valve, as I've stated at least twice now, give it time. Steam Deck adoption will not stop EAC v2, if Valve don't want to negotiate and provide support for features that should already be supported, than the SteamDeck doesn't support Fortnite - I can assure you should that be the case, SteamDeck users will turn on Valve in a heartbeat.

But such a scenario is highly unlikely, I see no reason whatsoever why Valve wouldn't be haggling out the specifics as we argue semantics over what might happen. I'm not interested in the elusive crystal ball, I intend to remain open minded and reserve judgement when EAC v2 is released and the expected teething issues are sorted out.

Your on Intel hardware Maz. Your CPU has a built in hard coded thread director. Yes very few software schedulers make a ton of difference on your hardware.

Well at least now you have progressed to this is the list of stuff you can't use but it all sucks anyway.

I don't think Gabe is going to care if users of the Steam deck say GIVES US our fortnight. There is zero chance Valve gives any control over their OS to Epic.

 

[ChadD]

You can style Grub with themes and wallpaper, it still looks better than Limine even with themes applied to both. I honestly never understood just why Cachy devs pushed Limine over Grub when both are equally capable bootloaders.

They don't push anything. Grub is right there if you want to use it.
https://wiki.cachyos.org/installation/boot_managers/
As per their wiki;
Grub is still the option to choose if you want to encrypt your boot for some reason and it supports more file systems.
Limine is best for Modern setups wanting snapshot booting + BIOS & UEFI + chainloading. Its cleaner and faster.

Anyway you can run what you like, that is the point of Linux and Arch specifically. Well you might have to also install something you don't like for a EAC kernel.

 

[CrimsonKnight13]

They don't push anything. Grub is right there if you want to use it.
https://wiki.cachyos.org/installation/boot_managers/
As per their wiki;
Grub is still the option to choose if you want to encrypt your boot for some reason and it supports more file systems.
Limine is best for Modern setups wanting snapshot booting + BIOS & UEFI + chainloading. Its cleaner and faster.

Anyway you can run what you like, that is the point of Linux and Arch specifically. Well you might have to also install something you don't like for a EAC kernel.

This exactly. I use btrfs snapshots on my desktop. Plus I dislike GRUB's config schemas & operational functionality comparatively to Limine

 

[Mazzspeed]

Your on Intel hardware max. Your CPU has a built in hard coded thread director. Yes very few software schedulers make a ton of difference on your hardware.

Well at least now you have progressed to this is the list of stuff you can't use but it all sucks anyway.

I don't think Gabe is going to care if users of the Steam deck say GIVES US our fortnight. There is zero chance Valve gives any control over their OS to Epic.

I'm running a 10th gen i9 X-Series procesor, there's no P or E cores, all cores are equal and there's no need for a hardware thread director. As for Valve, Valve aren't 'giving' any part of their OS to EPIC, these features should already be part of every Linux distro including SteamOS - the fact Steam OS lacks such functionality indicates to me that it's no more than a console OS and I'm simply not interested in either the OS or it's development.

Stating Gabe won't care if the SteamDeck doesn't support Fortnite is somewhat of a stretch, I guess we'll see in good time.

They don't push anything. Grub is right there if you want to use it.
https://wiki.cachyos.org/installation/boot_managers/
As per their wiki;
Grub is still the option to choose if you want to encrypt your boot for some reason and it supports more file systems.
Limine is best for Modern setups wanting snapshot booting + BIOS & UEFI + chainloading. Its cleaner and faster.

Anyway you can run what you like, that is the point of Linux and Arch specifically. Well you might have to also install something you don't like for a EAC kernel.

I know it is, I used the option. But from memory the default bootloader should you not select an alternative was Limine.

Anyway you can run what you like, that is the point of Linux and Arch specifically. Well you might have to also install something you don't like for a EAC kernel.

Gawd damn. You don't have to install 'anything', all you need is a signed kernel and signed drivers; everything else is already part of Linux and has been for quite some time now. CachyOS devs are providing scripts that run when you click "Enable EAC Mode" to toggle settings for the existing features as needed as a matter of convenience.

This exactly. I use btrfs snapshots on my desktop. Plus I dislike GRUB's config schemas & operational functionality comparatively to Limine

As stated, btrfs snapshots work 'perfectly' under Grub, it's literally two simple commands enabling btrfs snapshot support under Grub. If my CachyOS system boots faster than my KDE Neon system, the difference is basically imperceptible.

 

[ChadD]

I'm running a 10th gen i9 X-Series procesor, there's no P or E cores, all cores are equal and there's no need for a hardware thread director. As for Valve, Valve aren't 'giving' any part of their OS to EPIC, these features should already be part of every Linux distro including SteamOS - the fact Steam OS lacks such functionality indicates to me that it's no more than a console OS and I'm simply not interested in either the OS or it's development.

Stating Gabe won't care if the SteamDeck doesn't support Fortnite is somewhat of a stretch, I guess we'll see in good time.

I know it is, I used the option. But from memory the default bootloader should you not select an alternative was Limine.

As stated, btrfs snapshots work 'perfectly' under Grub, it's literally two simple commands enabling btrfs snapshot support under Grub. If my CachyOS system boots faster than my KDE Neon system, the difference is basically imperceptible.

I stand corrected yes you don't have a thread director. Regardless Sched-ext isn't useless. AND it is one Linux feature that is not going to work with EAC2. In fact sched-ext as we are talking about Valve, the default deck scheduler is LAVD. And yes on deck hardware it makes a major difference.

Valve doesn't turn on secure boot cause they are selling you hardware for you to own. The Deck and the Cube ship without secure boot, but they have left it in setup mode. If you want to use another OS and use Secure boot they aren't stopping anyone. I assume they feel the choice is the users. Valve doesn't even include a secure boot on option, if you want secure boot you have to setup your own MS keys.

Valve is a handful of old school neck beards. Everything they have done they have open sourced. I really don't see them doing secure boot. To support this they would have to start shipping their hardware with keys as Microsoft as the gate keeper. Valve is independent of anything MS. I really don't believe anyone actually thinks Valve is going to go back on that and start shipping secure boot keys. Not to mention that Micorsoft has a history or breaking Linux secure boot installs. Valve also encourages a bunch of community projects that would all break should they move to secure boot. IMO secure boot on the deck would be a nightmare for Valve. I doubt they want to deal with the added customer support to support Epic and fortnight. As I said before no one has ever bought a deck expecting to play fortnight. Nothing is being taken away form users in not breaking SteamOS for right now one non Valve game.

Also not shooting on grub don't care. The only point I made is you keep saying the EAC2 stuff is no big deal. WELL no it is a big deal. It locks people into a very specific setup. You like KDE Neon and all its defaults are good to go and you like it cool. Cachy (and arch) exist as a swiss army knife distro. Some of us run Systemd boot, some grub, Some rEFInd. Some run the standard EEVDF scheduler some cutom build BORE, some use Sched-ext. Some use Kyber IO some use Adios some use good old BFQ for thier spinners. All sorts of options and everyone runs what they like all on the same base. Its cool, its open, its ultimate choice. Hey EAC2 is a choice as well, Peter will make it work with Cachy... if your willing to either switch to or side load the things EAC2 requires. I agree with you its a choice, and generally obviously I believe choice is good. I don't think EAC2 is a good choice for all the reasons we have been over.

And yes at the end of the day 75% of my objection is EPIC. I don't trust Epic. This is a company that has supported Linux for 2 weeks. Why would I trust Epic they have built no trust with the LInux community. (Peter says they ahve been cool, well I should hope so they have no pull at this point they best be cool) Valve on the other hand has built EVERYTHING that makes gaming work on Linux right now. Proton, DXVK, VKD3D... they have contributed to MESA directly, the Kernel directly, sched-ext, Gamescope, KDE (Valve directly funds them), Fossilize, Zink, Steam Audio, OpenVR, They open sourced the source engine, when they made a console like VR headset using a custom(ish) ARM CPU, they opensourced ALL the tools they created like Leapton, and have funded FEX.
So yes another long post, to say yes I trust Valve. I don't trust EPIC even a little bit. Epic is not a company I respect in anyway. As cool as the unreal engine has been, Epic from their store to their invasive anti cheats and shit head leader. I just don't trust them at all. Their proposal puts way to much power in their hands. They haven't earned that level of trust imho.

 

[Mazzspeed]

I stand corrected yes you don't have a thread director. Regardless Sched-ext isn't useless. AND it is one Linux feature that is not going to work with EAC2. In fact sched-ext as we are talking about Valve, the default deck scheduler is LAVD. And yes on deck hardware it makes a major difference.

And via a simple toggle you can switch to the unsigned kernel and use it, so from your perspective nothing's lost. I fail to see how a default scheduler is going to affect EAC v2.

Valve doesn't turn on secure boot cause they are selling you hardware for you to own. The Deck and the Cube ship without secure boot, but they have left it in setup mode. If you want to use another OS and use Secure boot they aren't stopping anyone. I assume they feel the choice is the users. Valve doesn't even include a secure boot on option, if you want secure boot you have to setup your own MS keys.

I think we're all pretty much aware of this.

Valve is a handful of old school neck beards. Everything they have done they have open sourced. I really don't see them doing secure boot. To support this they would have to start shipping their hardware with keys as Microsoft as the gate keeper.

So Valve are old school neck beards, but Canonical aren't because they have their own keys supplied by the usual shim signed with a MS certificate to work with the MS keys built into the UEFI of most motherboards? C'mon Chad, there's no neckbeards, there's no gatekeepers, this isn't the big deal you're attempting to make it out to be.

Also not shooting on grub don't care. The only point I made is you keep saying the EAC2 stuff is no big deal. WELL no it is a big deal. It locks people into a very specific setup.

It doesn't lock anyone into anything they don't want, you still have options. Click the EAC v2 mode and you reboot into an environment with the exact same kernel you were running before the reboot - just signed, and specific scripts run to toggle the features already built into Linux as required by EAC v2. Click the toggle again and you're back to running an unsigned kernel with all settings changed back to whatever they were before you clicked EAC v2 mode.

It's really not a big deal.

Cachy (and arch) exist as a swiss army knife distro. Some of us run Systemd boot, some grub, Some rEFInd. Some run the standard EEVDF scheduler some cutom build BORE, some use Sched-ext. Some use Kyber IO some use Adios some use good old BFQ for thier spinners. All sorts of options and everyone runs what they like all on the same base. Its cool, its open, its ultimate choice. Hey EAC2 is a choice as well, Peter will make it work with Cachy... if your willing to either switch to or side load the things EAC2 requires. I agree with you its a choice, and generally obviously I believe choice is good. I don't think EAC2 is a good choice for all the reasons we have been over.

And they can still twiddle knobs all they like, the ability to do so isn't being forcibly removed. It's a toggle to run EAC v2, hardly rocket science - I actually think it's a pretty cool implementation, and may possibly end up being a big selling point for CachyOS as a distro. I see no reason why you can't enable different I/O schedulers considering they're not generally swapped on the fly.

I don't think EAC2 is a good choice for all the reasons we have been over.

Yep, I got it pages ago. I'm open to the implementation, judgement is reserved for when it's released and the kinks have been ironed out. I'm not just gonna say "NO" because FOSS.

And yes at the end of the day 75% of my objection is EPIC. I don't trust Epic. This is a company that has supported Linux for 2 weeks.

And yet Epic seem to be very transparent and open to discussion, as for 2 weeks - they've obviously gotta start somewhere?!

Why would I trust Epic they have built no trust with the LInux community. (Peter says they ahve been cool, well I should hope so they have no pull at this point they best be cool) Valve on the other hand has built EVERYTHING that makes gaming work on Linux right now. Proton, DXVK, VKD3D... they have contributed to MESA directly, the Kernel directly, sched-ext, Gamescope, KDE (Valve directly funds them), Fossilize, Zink, Steam Audio, OpenVR, They open sourced the source engine, when they made a console like VR headset using a custom(ish) ARM CPU, they opensourced ALL the tools they created like Leapton, and have funded FEX.
So yes another long post, to say yes I trust Valve. I don't trust EPIC even a little bit. Epic is not a company I respect in anyway. As cool as the unreal engine has been, Epic from their store to their invasive anti cheats and shit head leader. I just don't trust them at all. Their proposal puts way to much power in their hands. They haven't earned that level of trust imho.

They gave us EAC didn't they? As stated earlier: Sure, Tim's a little whiny bitch, but if it wasn't for Epic many games under Linux simply wouldn't work right now - That's gotta be worth something. Also, I don't believe Valve developed sched-ext.

We know your perspective on the implementation, do we really need to continue this back and forth rhetoric? How about we stick to the bullet points as things evolve and discuss progress (or, perhaps, the lack thereof) as opposed to this pointless argument on personal perspectives? I'm not all for this, but I'm open to what transpires. I've enabled all features required by EAC, there's been no issues whatsoever and my custom I/O schedulers work fine.

 

[DukenukemX]

Hey EAC2 is a choice as well, Peter will make it work with Cachy... if your willing to either switch to or side load the things EAC2 requires. I agree with you its a choice, and generally obviously I believe choice is good. I don't think EAC2 is a good choice for all the reasons we have been over.

As long as I can switch kernels when I don't play Fortnite then why should I care? It sucks that you gotta reboot to switch kernels but if you really want to Fortnite then it's an option. It also opens up other games with their anti-cheat on Linux.

And yes at the end of the day 75% of my objection is EPIC. I don't trust Epic. This is a company that has supported Linux for 2 weeks. Why would I trust Epic they have built no trust with the LInux community. (Peter says they ahve been cool, well I should hope so they have no pull at this point they best be cool) Valve on the other hand has built EVERYTHING that makes gaming work on Linux right now. Proton, DXVK, VKD3D... they have contributed to MESA directly, the Kernel directly, sched-ext, Gamescope, KDE (Valve directly funds them), Fossilize, Zink, Steam Audio, OpenVR, They open sourced the source engine, when they made a console like VR headset using a custom(ish) ARM CPU, they opensourced ALL the tools they created like Leapton, and have funded FEX.
So yes another long post, to say yes I trust Valve. I don't trust EPIC even a little bit. Epic is not a company I respect in anyway. As cool as the unreal engine has been, Epic from their store to their invasive anti cheats and shit head leader. I just don't trust them at all. Their proposal puts way to much power in their hands. They haven't earned that level of trust imho.

I don't see Epic trying to pull a fast one and take over the Linux market. Epic recognized that Linux is getting bigger and will now support it. Epic is also working with Valve to implement this into their Steam Deck, so it has some approval from Valve. Pretty sure CachyOS will make this an optional kernel, meaning it won't even be the default. There's no proprietary code in it.

 

[ChadD]

So Valve are old school neck beards, but Canonical aren't

Correct. Yes that is the situation. Canonical is a for profit server company that no one really much likes. Did you not know that? The have earned good will over the years and then burned it more then once.

It's really not a big deal.

You keep saying that but as I watch Cachy Peter continue to twist and turn trying to push it in... force installing EAC compliant boot loaders if one isn't there. Removing support for hardware. I don't know at least in terms of cachy its not going to be as smooth as most would like. I get it first implementation might smooth out. Still if things like the boot loader support happens, its only going to be from a result of multiple projects twisting their bits to fit.

And they can still twiddle knobs all they like, the ability to do so isn't being forcibly removed. It's a toggle to run EAC v2, hardly rocket science - I actually think it's a pretty cool implementation, and may possibly end up being a big selling point for CachyOS as a distro. I see no reason why you can't enable different I/O schedulers considering they're not generally swapped on the fly.

Peter has said sched-ext is out of the EAC kernel. Its going to be a standard EEVDF scheduler. I'm not knocking the scheduler or arguing that X or Y is 2% faster here or there whatever. Its a choice removed. In that specific case ya its something a lot of people use to squeeze performacne out of games.

Yep, I got it pages ago. I'm open to the implementation, judgement is reserved for when it's released and the kinks have been ironed out. I'm not just gonna say "NO" because FOSS.

That is fair no one has to.

And yet Epic seem to be very transparent and open to discussion, as for 2 weeks - they've obviously gotta start somewhere?!

Sure they gotta start somewhere. And the first place they started was making Linux more like Windows. Yay.

They gave us EAC didn't they? As stated earlier: Sure, Tim's a little whiny bitch, but if it wasn't for Epic many games under Linux simply wouldn't work right now - That's gotta be worth something. Also, I don't believe Valve developed sched-ext.

We know your perspective on the implementation, do we really need to continue this back and forth rhetoric? How about we stick to the bullet points as things evolve and discuss progress (or, perhaps, the lack thereof) as opposed to this pointless argument on personal perspectives? I'm not all for this, but I'm open to what transpires. I've enabled all features required by EAC, there's been no issues whatsoever and my custom I/O schedulers work fine.

I didn't say they developed Sched-ext. I said they contributed which they have. I also listed the kernel and mesa they didn't make these either. My point is they PAY people to work on them, and Vavle employees contribute code. You are correct we don't have to argue about this anymore. Your happy to run this. Cool. I don't think this is going to go anywhere. Cachy isn't important, neither is KDE Neon or Fedora or any non SteamOS distro to Epic frankly. The #s Epic cares about are on Valve hardware. Sweeney wants to get steam deck fortnight installs so he doesn't have to admit how fast fortnight customer base is shrinking. A million or so deck installs might help with that short term. When inevitabley Valve has nothing to say on the matter, or comes out and says no thanks. I believe Epic lets the project twist if they don't just abanodon the effort. As you say time will tell.

 

[ChadD]

As long as I can switch kernels when I don't play Fortnite then why should I care? It sucks that you gotta reboot to switch kernels but if you really want to Fortnite then it's an option. It also opens up other games with their anti-cheat on Linux.

Depends on the distro your on and the implmentation your dealing with I imagine. And granted nothing is shipping at this point. Going through the CachyOS pulls and Git Discusions. The cachy implemntaiton is going to be a little more then just a reboot. First if your not using systmed boot it sounds like the kernel is going to require it and Peter is working on isntall scripts to add systemd boot along side other bootloaders.
My main issue with the opening up other games... Is we do have a lot of unreal engine games in Linux that run just fine no issues. If Epic convinces most of them to switch to EAC2. We may end up having to boot this secure kernel for games we are currently playing as is. If Epic does turn around and say na Linux is a hot bed of cheating we are out in a year... I guess all those games go with them too.

I don't see Epic trying to pull a fast one and take over the Linux market. Epic recognized that Linux is getting bigger and will now support it. Epic is also working with Valve to implement this into their Steam Deck, so it has some approval from Valve. Pretty sure CachyOS will make this an optional kernel, meaning it won't even be the default. There's no proprietary code in it.

They can't take over the Linux market. I'm more cynical then that. I don't trust sweeney at all. Announcing EAC2 the way he did with a "we are talking to Valve" means Valve hasn't agreed to this in anyway. Epic is going to try and strong arm some control over the Linux ecosystem by trying to force Valve to adopt measuers for their anti cheat. I also doubt highly this solution, which on its face isn't inanely terrible is the end goal. Once Epic has most distros and maybe even valve having customers dual booting Linux with Linux. Well then they are a few annoying cheaters away from saying well now we need X to support Linux. Anti cheat in windows has always been a hamster wheel right? The first windows anti cheat wasn't a memory resident kernel level watchdog that ran when you booted your computer and stuck around even if you uninstalled the game it rode in on. That is where the cycle of shittier things ended. I don't really want Linux to even step a foot on the wheel. IMO Valve is right. Real Serious anti cheat is server and AI based. Client side anti cheat just isn't ever going to be perfect. The only way to really police cheaters is for the develper to actually POLICE their game. Another reason I don't see Valve jumpin in on making SteamOS EAC2 compliant. They have been championing VACnet and AI flagging for human confirmation over invasive client side anti cheat, that isn't very good anyway.

 

[Mazzspeed]

Correct. Yes that is the situation. Canonical is a for profit server company that no one really much likes. Did you not know that? The have earned good will over the years and then burned it more then once.

I refuse to use Vanillla Ubuntu, but I have no problem with distro's based on Ubuntu; right now I'm pretty pissed off with CachyOS. Last I checked, Valve were a for profit company...

You keep saying that but as I watch Cachy Peter continue to twist and turn trying to push it in... force installing EAC compliant boot loaders if one isn't there. Removing support for hardware. I don't know at least in terms of cachy its not going to be as smooth as most would like. I get it first implementation might smooth out. Still if things like the boot loader support happens, its only going to be from a result of multiple projects twisting their bits to fit.

EAC compliant boot loaders? C'mon dude, Limine sacrifices measured boot and TPM attestation for a tiny bit more speed, Peter had to make some compromises in order to get things to work - I hardly see Peter complaining about it to the extent you are.

Peter has said sched-ext is out of the EAC kernel. Its going to be a standard EEVDF scheduler. I'm not knocking the scheduler or arguing that X or Y is 2% faster here or there whatever. Its a choice removed. In that specific case ya its something a lot of people use to squeeze performacne out of games.

And, once again *sigh*, you can swap to the default kernel if you want to run sched-ext. You have options, stop criticizing others that also want options that suit their specific use case.

And the first place they started was making Linux more like Windows. Yay.

Linux gaming reached the peak of the bell curve, there literally wasn't a single game in my library I couldn't play, then kernel level AC was released under Windows. Right now it's on the decline of the bell curve due to kernel level AC under Windows - and your solution to that is people should just run Windows? People want to play games under the OS of their choosing, options still exist for those that aren't open to the idea. For someone that stated they weren't going to criticize the opinions of others, I'm telling you "you're doing precisely that".

We get it, you're worried all games are going to switch to EAC v2 and you're gonna be left on the bench at the Prom - understand, if you are, that's your choice. Cheaters are out of control, we needed a better AC implementation that was fair; I simply cannot see how Epic could have made their proposal any fairer considering the direction of not Windows, but gaming in general.

I didn't say they developed Sched-ext. I said they contributed which they have. I also listed the kernel and mesa they didn't make these either. My point is they PAY people to work on them, and Vavle employees contribute code. You are correct we don't have to argue about this anymore. Your happy to run this. Cool. I don't think this is going to go anywhere. Cachy isn't important, neither is KDE Neon or Fedora or any non SteamOS distro to Epic frankly. The #s Epic cares about are on Valve hardware. Sweeney wants to get steam deck fortnight installs so he doesn't have to admit how fast fortnight customer base is shrinking. A million or so deck installs might help with that short term. When inevitabley Valve has nothing to say on the matter, or comes out and says no thanks. I believe Epic lets the project twist if they don't just abanodon the effort. As you say time will tell.

You're reaching. Without EAC, gaming under Linux would be in an even worse state right now - it's that simple. Let it go dude.

The cachy implemntaiton is going to be a little more then just a reboot. First if your not using systmed boot it sounds like the kernel is going to require it and Peter is working on isntall scripts to add systemd boot along side other bootloaders.

Assuming you're not a neckbeard hanging onto the whole systemd vs init argument running Gentoo and compiling from source, it will be nothing more than a reboot under CachyOS.

You are correct we don't have to argue about this anymore. Your happy to run this. Cool. I don't think this is going to go anywhere.

I never said "I was happy to run this", from the onset I've stated time and time again I understand we need a solution to AC under Linux and I'm open to Epic's proposal and look forward to seeing what comes of it - I reserve judgement until it's implemented and the kinks are ironed out. However, you are right, you're not going to convince me of anything based on speculation.

Another reason I don't see Valve jumpin in on making SteamOS EAC2 compliant. They have been championing VACnet and AI flagging for human confirmation over invasive client side anti cheat, that isn't very good anyway.

Yeah...I'm not seeing a connection here.

Let it go Chad, let people discuss this implementation as it unfolds without the neckbeard perspective. You still have options, the reality is you fear games jumping to EAC v2 as you're hellbent on avoiding it. I just wanna play my games under the OS of my choosing in a way that impacts others as little as possible.

 

[Mazzspeed]

Nobara is now secureboot and EAC compliant:

https://www.reddit.com/r/NobaraProj...nobara_is_now_secureboot_and_eacv2_compliant/

Their Wiki page actually has come handy commands under step 4 allowing you to ensure various Linux features are set correctly in order to support EAC v2. With the exception of the last command, these all work on any distro:

https://wiki.nobaraproject.org/secureboot

 

[DukenukemX]

My main issue with the opening up other games... Is we do have a lot of unreal engine games in Linux that run just fine no issues. If Epic convinces most of them to switch to EAC2. We may end up having to boot this secure kernel for games we are currently playing as is. If Epic does turn around and say na Linux is a hot bed of cheating we are out in a year... I guess all those games go with them too.

Single player or multiplayer games? If it's multiplayer then we're already in this situation where Linux users can't play multiplayer games with anti-cheat. So if Epic pulls out then we're right back to square one. Considering how much market share Linux has grown then Epic pulling out may not be a good option.

They can't take over the Linux market. I'm more cynical then that. I don't trust sweeney at all. Announcing EAC2 the way he did with a "we are talking to Valve" means Valve hasn't agreed to this in anyway.

If Valve doesn't agree then that's a red flag. Then I'd agree and say this isn't looking very Newell.

Epic is going to try and strong arm some control over the Linux ecosystem by trying to force Valve to adopt measuers for their anti cheat. I also doubt highly this solution, which on its face isn't inanely terrible is the end goal. Once Epic has most distros and maybe even valve having customers dual booting Linux with Linux. Well then they are a few annoying cheaters away from saying well now we need X to support Linux. Anti cheat in windows has always been a hamster wheel right? The first windows anti cheat wasn't a memory resident kernel level watchdog that ran when you booted your computer and stuck around even if you uninstalled the game it rode in on. That is where the cycle of shittier things ended. I don't really want Linux to even step a foot on the wheel. IMO Valve is right. Real Serious anti cheat is server and AI based. Client side anti cheat just isn't ever going to be perfect. The only way to really police cheaters is for the develper to actually POLICE their game. Another reason I don't see Valve jumpin in on making SteamOS EAC2 compliant. They have been championing VACnet and AI flagging for human confirmation over invasive client side anti cheat, that isn't very good anyway.

I agree that client side anti cheat is stupid. Fortnite isn't in a good position and Epic had to fire 1,000 employees. This is them desperate to maintain some users by catering to Linux. Worst case scenario Linux loses Fortnite. Best case scenario Linux gains an anti-cheat system that satisfies multiplayer games. If Epic doesn't gain the blessing of Valve then I would avoid this. I would avoid this anyway because this is for Fortnite, but whatever.

 

[auntjemima]

Sooooooo I am kinda new to the news.. yep.

Not being able to play fortnite is really the only thing I missed from Windows, so this seemed like good news. Then I saw it needs secure boot. Guess my Arch distro is out lol

 

[Nobu]

Sooooooo I am kinda new to the news.. yep.

Not being able to play fortnite is really the only thing I missed from Windows, so this seemed like good news. Then I saw it needs secure boot. Guess my Arch distro is out lol

Why? I have secureboot set up on mine. Sure, it's not point and click, but it's not super hard either. All the instructions are in the wiki.

 

[Mazzspeed]

Why? I have secureboot set up on mine. Sure, it's not point and click, but it's not super hard either. All the instructions are in the wiki.

You can't use self signed keys...

 

[ChadD]

Why? I have secureboot set up on mine. Sure, it's not point and click, but it's not super hard either. All the instructions are in the wiki.

The requirements are more strict then that, signed kernel is one of the requirements. Arch proper isn't going to be signing kernels for Epic. EDIT: and I'm slow Maz got it. Yes your kernel has to be signed by the distro. Epic plans to keep their own trusted list.

 

[Nobu]

You can't use self signed keys...

oh well... Anyway, while I was checking all this I realized the systemd service I made wasn't copying my stub to the efi directory because I removed the linux pkg (I'm running linux-rt) and it assumes that files related to that are present.

I fixed that and got apparmor enabled for real (I had it installed but gave up configuring it for whatever reason).

Now I'm moar secure for when I start looking up nudes using sketchy AppImages like Heroic or Epic.

 

[Bankie]

I can't imagine trusting anything coming out of Tim Sweeney or anything he's involved with. I'm at the point that any game using EOS/EAC or Unreal Engine automatically requires extra consideration; it's as bad as Denuvo.

There aren't enough games that both use EAC and don't work on Linux to even care. According to https://www.gamingonlinux.com/anticheat/status/broken/ there are only 27 games TOTAL that don't work on Linux because of EAC. It's mainly Fortnight, Rust, and Apex Legends; all of which have been declining for years. Everyone would be better off if this got shelved; people outside of Epic Games can figure a Linux anti-cheat out.

 

[auntjemima]

I can't imagine trusting anything coming out of Tim Sweeney or anything he's involved with. I'm at the point that any game using EOS/EAC automatically requires extra consideration; it's as bad as Denuvo.

There aren't enough games that both use EAC and don't work on Linux to even care. According to https://www.gamingonlinux.com/anticheat/status/broken/ there are only 27 games TOTAL that don't work on Linux because of EAC. It's mainly Fortnight, Rust, and Apex Legends; all of which have been declining for years. Everyone would be better off it this got shelved; people outside of EG can figure an AC out.

Yeah, for me it's only fortnite and even then it wasn't enough to keep me on Windows. Was a nice game to play some quick 20 minutes matches when the time was there. Oh well. Been on Arch for a couple years now.

 

[Mazzspeed]

I can't imagine trusting anything coming out of Tim Sweeney or anything he's involved with.

He may be able to get away with underhanded tactics under Windows, but I find it unlikely he'd be able to get away with underhanded tactics regarding the Linux community. Even running as root, ebpf lsm is quite limited compared to anything under Windows. It's not like he's tried anything manipulative regarding the current implementation of EAC under Linux.

Tim's just a whiny little bitch is all.

 

[Bankie]

He may be able to get away with underhanded tactics under Windows, but I find it unlikely he'd be able to get away with underhanded tactics regarding the Linux community. Even running as root, ebpf lsm is quite limited compared to anything under Windows. It's not like he's tried anything manipulative regarding the current implementation of EAC under Linux.

Tim's just a whiny little bitch is all.

He is. But he's also really loud. This entrance feels suspect to me. It wasn't that long ago that Tim was shitting on Linux; he must see that they've lost the Windows majority and now need to save face among the Linux users he used to deride. EGS was already found to be scanning Steam accounts after it was installed. Anything outside of UE at this point is self preservation and cannot be trusted.

 

[Mazzspeed]

He is. But he's also really loud. This entrance feels suspect to me. It wasn't that long ago that Tim was shitting on Linux; he must see that they've lost the Windows majority and now need to save face among the Linux users he used to deride. EGS was already found to be scanning Steam accounts after it was installed. Anything outside of UE at this point is self preservation and cannot be trusted.

I admit, I don't like Tim. However Epic's announcement regarding EAC v2 seemed quite open to anyone in the Linux commuity including leaders in the community. I trust the community to do the right thing in the face of little Timmy.

EDIT: In other news I managed to remove the file system lock and repair my CachyOS install. Do data lost, no harm done.

 

[DukenukemX]

Tim Sweeney has to remind everyone how stupid he is. He better hope Valve accepts his EAC-V2 anti-cheat.

 

[GoldenTiger]

Tim Sweeney has to remind everyone how stupid he is. He better hope Valve accepts his EAC-V2 anti-cheat.
View attachment 834048
View attachment 834049

He's right on all of what you just screenshotted, though?

 

[CrimsonKnight13]

He's right on all of what you just screenshotted, though?

Eh, what? He always acts like he's the higher moral authority over Valve. Never fails.

 

[sharknice]

Bros have TDS

 

[Prince Valiant]

I don't particularly disagree on Steamworks, but it's not as if the others wanted to play ball on cross platform MP until recently or let users host (perish the thought). As for the AI bit, why should anyone would care about developers and publishers being forced to divulge anything?

 

[Mazzspeed]

People need to remember that Valve tackled the gaming problem under Linux to look after Valve as a company, they didn't do it to look after Linux users.

 

[DukenukemX]

He's right on all of what you just screenshotted, though?

You missed the part where he agreed he's wrong but then makes it seem like Valve is peer pressuring everyone. Community notes were correct in both.