Quoting: Avehicle7887Bad reply on GOG's side, I think they had better not reply at all than throwing the silly 'Install Windows' response.

Instead of the Steam Deck, I think GOG should support Linux on the desktop to begin with.

Yeah, supporting Deck officially isn't a trivial project like some might think. I.e. like making sure games work with the controller, making controller work without Steam and so on. I have no idea if there is a way to do it now even and how.

But proposing to install Windows isn't a solution to any of that, so such kind of answer is ridiculous.

I agree, GOG should focus on improving desktop Linux support, before trying to support Deck if they decide to.

View this comment - View article - View full comments

I think Feral are out of porting business, so lack of support is not surprising. What are they doing these days?

View this comment - View article - View full comments

Quoting: CatKillerNo, they won't.

If they have only dumb PR people - they won't.

View this comment - View article - View full comments

Sounds like a dumb response of some clueless PR person. They'll revise their answer soon, becasue it was a pretty bad PR :)

View this comment - View article - View full comments

lol that trailer is bizarre enough to be funny :grin:

The first one didn't support Linux

I see Linux is listed as supported for the first game on itch.io: https://sos.itch.io/mcpixel [External Link]

And it's on sale there now.

UPDATE: From the listing, it looks like it's using Adobe Air, which might a problem and reason Steam doesn't list it.

View this comment - View article - View full comments

Quoting: pete910Particular reason why ?

Can't say specifially about Feral, but some older Linux games are OpenGL only, and perform worse than their Windows versions going through DX → Vulkan path.

Not sure if this testing takes performance into account.

This should be better for modern native Linux games that are supposed to all use Vulkan these days.

View this comment - View article - View full comments

Quoting: RCLE.g. they flag stuff like an unfamiliar dynamic library being mapped to the game's address space or certain parts of the process memory not being the same as they expect - that's usually the extent of their "spying". They have no interest to "spy" on things that a user would be concerned about (like e.g. files or what not)
<...>
But I totally understand that this can all sound very abstract. And especially if there's no trust towards the developer, the very fact of allowing their software to hook up to the kernel can be a big no-no.

May be I should rephrase the above a bit. It's designed to enforce something as an expression of that lack trust. You can call it "spy" in a sense that this policing tool monitors something in your private space (up to the kernel) becasue it doesn't trust you. That fact alone (regardless of what exactly it's monitoring) I think is a good enough reason not to trust it in return and assume that it could do more than it declares it wants to do.

Which is basically what you expressed in that last sentence as well, so we don't really disagree.

View this comment - View article - View full comments

Quoting: RCLWell, this is a grim way to look at things, although I don't blame you for taking that POV.

Not so much grim as simply more security conscious approach. You wouldn't want to trust those who don't trust you. It's not like you know the other side is a crook, but if they treat you as an a priory potential crook, you should do the same to them, it's only fair.

Quoting: RCLHowever, IMHO the situation is more analogous with, say, airport security. Both sides assume the good will of the other, but it needs to be enforced. However, the enforcement isn't arbitrary - there are accepted limits what can be checked and what cannot, and everything is done in a respectful manner.

I think the core difference is that such kind of security is external to your private space. I.e. imagine you get agents in your home all the time, because anyone can be a potential threat. Digital space is more abstract, but there is still the sense of private space there too. Like your computer, your OS it runs, programs that run on your OS and etc. It's not that policing in general is a problem, it's policing your private space that is and that's the core of this issue above.

Quoting: RCLOf course among the Linux users, especially typical users, there's very little, if any, trust to closed source in general, and to closed source kernel components in particular. However, Linux gamers are crossing the boundaries - a lot of us do not mind running many closed source components on the system (the games themselves), including the drivers. Again, in that case anti-cheat doesn't stand out that much.

Lack of trust for blobs is not unreasonable, but I'd argue blobs in general can be more neutral due to their goals. I.e. some normal game doesn't have a goal of spying on you, even though it could since it's a blob and you don't really know fully what it could do. But anti-cheat? It's explicitly designed to spy on you (though formally just for the narrow purposes related to the game). I'd say in regards to trust it's like in a whole worse category than other blobs above due to that.

View this comment - View article - View full comments

Quoting: RCLWhile I agree with you, I want to stress that anti-cheat isn't a malicious software that has no boundaries. Anti-cheats are governed by EULAs which sets the limits of what they are allowed (by the user accepting the EULA) to do (e.g. https://www.easy.ac/en-us/support/cardlife/account/eula/ [External Link]). In principle, the situation with trusting the anti-cheat does not really differ from trusting the closed source kernel you're running on other platforms, or closed source binary drivers (or firmware) you might be running on Linux. In all these cases the trust between the user and the vendor is enforced via legal agreements that both sides accept as a reasonable compromise between the system's functionality and their control over the system. Different platforms (PC vs console) offer a different degree of that control, but in all cases they are based on the mutual agreement.

The problem with this (and same applies to DRM) is the very issue of trust that you bring. Users also need to accept the rules of the service, yet they still cheat, right? I.e. the company doesn't trust the user despite the EULA. And not only doesn't trust, but deploys spyware-like capabilities on user's system, meaning treating all users as suspects by default.

Now, why should the user trust the company in such situation? Trust goes both ways. That's the main pitfall of overreaching preemptive policing in general - those who use it don't have trust, but then why they themselves be trusted in return? Quite on the contrary, they also should never be trusted.

There was a neat illustration of this idea in this video:

https://www.youtube.com/watch?v=XgFbqSYdNK4 [External Link]

View this comment - View article - View full comments

Quoting: RCLbut I am not aware of any breakthroughs there.

I agree that making such solution is harder than it sounds, I don't doubt that. But I just don't see lack of current solution as a reason to erode users' privacy. Same as let's say lack of good self-driving AI isn't a reason to use some other poor solution that will endanger people's lives becasue self-driving itself is considered "cool" and someone says it has to be enjoyable already today.

This is actually a good comparison, because most people take such kind of security seriously and understand the implications of using inappropriate solutions. When it comes to information security - it's more abstract. And people more easily ignore issues with it like the above anti-cheat rootkits.

View this comment - View article - View full comments