@PurpleLibrary guy.
The answer to your question is in essention anti-cheat.
Much like the closed nature of windows makes it more attractive for anti-cheat solutions and drm than Linux, does the closed form of the xbox platform make it more attractive to anti-cheat solutions than pc. This ROG ally is a pc it doesn't matter how much it pretends otherwise.
Better DMCA protection, predictable OS(the last full jailbreak was at least a decade ago), etc.

View this comment - View article - View full comments

This is good news for desktop Linux and Valve.
They see the need to address the SteamDeck separately and not push needless extra stores.
EA'll intentionally be one of the latest to allow their software to run on desktop Linux systems.
They're fighting Valve and keeping Linux down means that Microsoft can keep Valve in check.
Yet they've SteamDeck became enough of unit on itself to be addressed separately even though with the same motivations(remember SteamDeck isn't even half of the Linux market share).
Lets hope they'll need a SteamOS and/or an Arch statement next time, because it shows effort on their part.
Every time they need to split the platform it means they're now dealing with two problems instead of one.

View this comment - View article - View full comments

@Cyba.Cowboy
I understand your excitement over arm, but am very certain this will not happen anytime soon.
X86 is AMD's oligopoly.
For X86_64 it's even the licensor instead of the licensee, while for ARM it would need to license again and before you say.
Also Apple's chips aren't competitors for AMD.
Apple never bought or considered buying AMD and it is not selling these chips to AMD customers(they're not selling these chips B2B full stop)

As such there are few ways to convince AMD to step away from x86.
One is proof that it's doomed in the short term, but it's latest models are competitive with Qualcomms ARM desktop processors in preformance and battery life(AMD's only realistic opponent from the ARM side).
Another is provide an opportunity for growth, but AMD is already growing faster than it can handle, because the market leaders in its two most major segments have left or self immolated(NIVIDIA went AI instead of productivity, Intel hasn't innovated on serious level for more than a decade).

View this comment - View article - View full comments

@gradyvuckovic Chess is older than d&d.
It's easier to imagine that people want to play what they see(a football game) than an individual part of what they see(the footballer).

Also it's easier to make.
FPV is hard and it still requires strategic simulation.

View this comment - View article - View full comments

i'll leave aside the usual "why do we even need another launcher" argument for a second to say this... why do game devs have such a hard time making well behaved launchers?! it's a windowed app folks, literally any app besides games got this right... it's really not rocket science! you're all embarassing yourselves in front of your customers before they even go into the game!

Launchers are a sign of strength not weakness.

Making launchers is hard and there is barely any opensource support for it.

Why do games still do it
1. Launchers are generally where the drm and anti-cheat are primarily based to the point that implementing launcher free drm is a challenge.
Games have separate launchers, because they consider Valve drm and anti-cheat inadequate or because they want to minimize their steam dependency.
2. Launchers allow you to advertise your company to gamers. Suddenly you've a special {company} program on your computer, which is named after the company instead of the product.
3. Not working with launchers means uploading your game binary to steam. This is a bigger problem than you think. Steam has used this access several times against the wishes of other parties: keeping games accessible to past licensees when the developer pulls the game from steam, Scrutinizing your game for viruses, etc.

View this comment - View article - View full comments

I'm a little worried about this, as if this is pushed on EU citizens, could they make it biased against specific political or philosophical searches?? Especially as a more 'conservative' person, I worry if the EU could use this against people trying to search for information that promotes right-wing or right-leaning ideas.

Outside of that, I don't really see the issue with our current search engine list. Google, DuckDuckGo, Brave, Bing, I've never had a issue with them.

@SirMCJeager It's good that you worry, I don't think they will, but only because concerned citizens like you exist.
On what is wrong with that list form an eu standpoint.
I can give you a few suggestions:
Each of these parties is stationed in the USA, which makes them basically by definition non-gdpr compliant, since Trump signed away the privacy shield.
This same Americanity also associates it with Trumps recent instability including his tendency to modify and forbid certain delivery of service in the EU.
Each of these parties has done exactly what you worry about the EU doing and often synchronous for one point, so they've reason to distrust them for that exact reason.

View this comment - View article - View full comments

This sounds like huge news.
Even if it is not that huge anymore physX has been king for long and it could at least allow us to support older titles and probably even compete with what people are using nowadays.

View this comment - View article - View full comments

@CatKiller, which is why each and every of my alternatives doesn't lock down the kernel.
the first one ignores the kernel existence by hardening the executable itself.
The second one only confirms the existence of the trusted functions(how it achieves that is even secondary).
The third one checks behavioral patterns in the firmware.

View this comment - View article - View full comments

@CatKiller
On alternate solutions to anti-cheat compatibility with anti-cheat.
I've been thinking about it and doing research.
I know I'm preaching to the choir, but you still get my proposed solutions.

1. Linktime ASLR(adress space layout randomization). This one is the most research based and the most "open". Most cheats work by mapping out the memory offsets of the program and using these to find the data and code they want to edit. This could be fixed by shipping different memory offsets. In theory all that is needed for this is an advanced linker script and relinking the code every time you ship a binary.
Attackers could still edit one binary and ship it to their customers, but a. that would upgrade their activity to copyright infringement(cheating is arguably legal, since you don't actually copy any code or assets and just modify what the vendor provided) and b. that is easily countered by giving each shipped version a random id and blocking the ones spotted too often from too many different ips at the same time.

There is no security through obscurity in this entire story, so publishing the source code wouldn't harm its effectiveness and you don't even harm individual modders that much.
2. Trusted KASLR(Kernel adress space layout randomization). KASLR is an individual Linux feature that as long it's not compromised should keep more cheaters away than the entire closedness of Windows. It's pretty Linux specific and its aimed goal is to keep hacked compromised kernel code from effectively accessing parts of the kernel it didn't need access to at compile time. It's not perfect, but much better than anything Apple or Microsoft offers. The problem is that it operates purely on your computer and as such you can read and edit it completely.
If you give something with root access the KASLR seed it can check if it has behaved like KASLR should behave, but also compromise KASLR.
The seed also changes every reboot.
I've thought up a protocol through which one can make the KASLR seed predictable only for parties with access to one of all seeds used after initializing it for this protocol, which maintains all the other security guarantees of KASLR, allowing Kernel level anti-cheat providers to provide their own initializing seed and theoretically checking for correct KASLR at their leisure.
The problem is that if one can observe during system boot the seed is used and can thus be extracted.
My hypothesis is that running this initialization step in a trusted execution environment or using homeomorphic encryption could bypass this problem.

Something both these solution have in common is that they're actually better than signed kernels, because they could work even if the entire firmware stack is controlled by the owner of the device.

3. Measured boot could work.

EDIT:
a drawback to solution 1 is that it's platform agnostic and might thus not be such a convincing argument to allow Linux to play a game.
The advantage is that it's the most "open" and vendor trusting solution.

View this comment - View article - View full comments

@Pyrate good observation.
They can't rule Linux gaming.
Valve is already on that path.
They can't rule x86 gaming Valve already does.
They can't rule Mac gaming, Apple does(they're a bad king, but still a king).
Releasing your own console is a risky business.
ARM Windows provides yet untried ground.

View this comment - View article - View full comments