Live data from Hacker News

GOG: Linux "the next major frontier" for gaming as it works on a native client

xda-developers.com

401–410 of 421 posts

Re: GOG: Linux "the next major frontier" for gaming as it works on a native client

#401

Earlier quoted context omitted.

> I don't think this is a given This is a given. They love Discord and shit like that.

Right, but that proves nothing, is there something that is more open and better than Discord, for this group of people? Otherwise I'd say my argument applies in exactly the same way. Pragmatism wins, so why change unless there is a need?

> is there something that is more open and better than Discord, for this group of people?

Matrix, xmpp, and probably more. The options are not lacking

Re: GOG: Linux "the next major frontier" for gaming as it works on a native client

#402

Earlier quoted context omitted.

> I don't think this is a given This is a given. They love Discord and shit like that.

They don’t care about FOSS, but they care about “computer lets me do what I want”. Discord is obviously proprietary but it’s actually a very modular platform that gives a lot of nice controls. It’s easy to make your own “server”, it’s easy to add whatever bots you want, it’s easy to moderate. From a consumer perspective, it’s “open”. Also, I know that this wasn’t your point, but I do feel compelled to point out that…

> From a consumer perspective, it’s “open”.

As open as windows that tracks everything that you do

Re: GOG: Linux "the next major frontier" for gaming as it works on a native client

#403
post #397
post #377

Earlier quoted context omitted.

So targeting windows isn't stable either? Which is why GOG even exists.

I'm asking what your game library is full of if most can't run on windows 11.

directX 5 :)

Re: GOG: Linux "the next major frontier" for gaming as it works on a native client

#404

Earlier quoted context omitted.

Alternatively, work on developing protocols for game launchers instead. Get the Heroic Launcher devs and devs from other launchers to work on a common interface.

You don't need launchers. Game is a simple application like any other. Just double click it...

In principle I agree with you. But people seem to like using a game-specific launcher for games like Steam, GOG, Heroic Launcher, Hydra Launcher, etc.

Re: GOG: Linux "the next major frontier" for gaming as it works on a native client

#405
post #274

Earlier quoted context omitted.

I don't find any advantages of having client of GoG games to be honest, updates was only one, but not in case with modding.

I like seeing my achievements and playtime (but also it's more of a nice to have)

Why? I find nothing interesting about it when I play a game.

Re: GOG: Linux "the next major frontier" for gaming as it works on a native client

#406
post #351

Earlier quoted context omitted.

It's really unfortunate the term "free software" took off rather than e.g. "libre software", since it muddies discussions like this. The point of "free software" is not "you don't have to pay," it's that you have freedom in terms of what you do with the code running on your own machine. Selling free software is not incompatible with free software: it's free as in freedom, not as in free beer.

Nobody in this comments thread appears to be confused by or misusing the term "free software". We're talking about free software vs (commercial) proprietary software. > I am still surprised most Linux Distros haven't changed their package managers to allow for selling of proprietary solutions directly

Free packages remain unaffected, but now there are optional commercial options you can pay for which fund the free (as in free money) infrastructure you already take advantage of so that these projects are fully sustainable. I imagine some open source projects could even set themselves up to receiving donations directly via package managers.

Re: GOG: Linux "the next major frontier" for gaming as it works on a native client

#407
post #351

Earlier quoted context omitted.

Nobody in this comments thread appears to be confused by or misusing the term "free software". We're talking about free software vs (commercial) proprietary software. > I am still surprised most Linux Distros haven't changed their package managers to allow for selling of proprietary solutions directly

Free packages remain unaffected, but now there are optional commercial options you can pay for which fund the free (as in free money) infrastructure you already take advantage of so that these projects are fully sustainable. I imagine some open source projects could even set themselves up to receiving donations directly via package managers.

I promise you, everybody understands the general idea, but adding a built-in store to your operating system is far from a neutral action that has no second- or third-order effects. It isn't that it somehow affects "free" packages. Incoming text wall, because I am not very good at being terse.

- It creates perverse incentives for the promotion of free software.

If development of the operating system is now funded by purchases of proprietary commercial software in the app store, it naturally incentivizes them to sell more software via the app store. This naturally gives an incentive to promote commercial software over free software, contrary to the very mission of free software. They can still try to avoid this, but I think the incentive gets worse due to the next part (because running a proper software store is much more expensive.)

Free software can be sold, too, but in most cases it just doesn't make very much sense. If you try to coerce people into paying for free software that can be obtained free of charge, it basically puts it on the same level as any commercial proprietary software. If said commercial software is "freemium", it basically incentivizes you to just go with the freemium proprietary option instead that is not just free software, but also often arguably outright manipulative to the user. I don't really think free software OS vendors want to encourage this kind of thing.

- It might break the balance that makes free software package repositories work.

Software that is free as in beer will naturally compete favorably against software that costs money, as the difference between $0 and $1 is the biggest leap. Instead of selling software you can own, many (most?) commercial software vendors have shifted to "freemium" models where users pay for subscriptions or "upsells" inside of apps.

In commercial app stores, strict rules and even unfair/likely to be outlawed practices are used to force vendors to go through a standardized IAP system. This has many downsides for competition, but it does act as a (weak) balance against abusive vendors who would institute even worse practices if left to their own devices. Worse, though, is that proprietary software is hard to vet; the most scalable way to analyze it is via blackbox analysis, which is easily defeated by a vendor who desires to do so. Android and iOS rely on a combination of OS-level sandboxing and authorization as well as many automated and ostensibly human tests too.

I am not trying to say that what commercial app stores do is actually effective or works well, but actually that only serves to help my point here. Free software app stores are not guaranteed to be free of malware more than anything else is, but they have a pretty decent track record, and part of the reason why is because the packaging is done by people who are essentially volunteers to work on the OS, and very often are third parties to the software itself. The packages themselves are often reviewed by multiple people to uphold standards, and many OSes take the opportunity to limit or disable unwanted anti-features like telemetry. Because the software is free, it is possible to look at the actual changes that go into each release if you so please, and in fact, I often do look at the commit logs and diffs from release to release when reviewing package updates in Nixpkgs, especially since it's a good way to catch new things that might need to be updated in the package that aren't immediately apparent (e.g.: in NixOS, a new dlopen dependency in a new feature wouldn't show up anywhere obvious.)

Proprietary software is a totally different ball game. Maintainers can't see what's going on, and more often than not, it is simply illegal for them to attempt to do so in any comprehensive way, depending on where they live.

If the distributions suddenly become app store vendors, they will wind up needing to employ more people full time to work on security and auditing. Volunteers doing stuff for free won't scale well to a proper, real software store. Which further means that they need to make sure they're actually getting enough revenue for it to be self-sustaining, which again pushes perverse incentives to sell software.

What they wanted to do is build a community-driven OS built on free software by volunteers and possibly non-profit employees, and what they got was a startup business. Does that not make the problem apparent yet?

- It makes the OS no longer neutral to software stores.

Today, Flatpak and Steam are totally neutral and have roughly equal footing to any other software store; they may be installed by default in some cases, but they are strictly vendor neutral (except for obviously in SteamOS). If the OS itself ships one, it lives in a privileged position that other software store doesn't. This winds up with the exact same sorts of problems that occur with Windows, macOS, iOS and Android. You can, of course, try to behave in a benevolent manner, but what's even better than trying to behave in a benevolent manner is trying to put yourself in as few situations as possible to where you need to in order to maintain the health of an ecosystem. :)

--

I think you could probably find some retorts to this if you wanted. It's not impossible to make this model work, and some distributions do make this model work, at least insofar as they have gotten now. But with that having been said, I will state again my strongly held belief that it isn't that projects like Debian or Arch Linux couldn't figure out how to sell software or don't know that they can.

It's just that they do not want to.

Re: GOG: Linux "the next major frontier" for gaming as it works on a native client

#408
post #20

Earlier quoted context omitted.

Off the top of my head Crime Cities on launch forced me to use Galaxy to play it. I vividly remember this because the game also ran like complete crap.

I had Crime Cities lying around since it was a freebie on GOG many years ago, so I just went ahead and installed it using vanilla wine. There was absolutely no Galaxy requirement for installing or playing the single player part of the game.

There isn't now. It was there at launch. It was removed at least several months after launch.

Re: GOG: Linux "the next major frontier" for gaming as it works on a native client

#409
post #49
post #14

I'm very hopeful that Linux gaming will save the open PC desktop despite big tech is coming to destroy it. Or at least keep PCs alive for another decade. Gamers are still a huge factor as hardware customers. GOG creating a Linux launcher and Steam Box with SteamOS coming out soon should benefit PC users in general not just gamers since Microslop sees Windows like a social experiment where they can test AI on unsuspec…

Steam developing proton was what made it possible for me to change fully. No dual boot or anything needed. It's great. Funnily I also run GoG games through steam proton.. But looking forward to the GoG client working!

I'm still wondering why Apple hasn't taken a few billion of their trillions and just built/bought a Proton style layer for macOS.

The computing power is there, we just need the ability to run Windows-only games on Macs with a single click.

Re: GOG: Linux "the next major frontier" for gaming as it works on a native client

#410

Earlier quoted context omitted.

If we have DRM with some private key, then I guess your idea is I download the game files and some private key and that allows me to run the game. If I can send you the private key and the game and it allows you to run the game with no further inputs, then the DRM is trivially broken (even without open source). If it does some online check, then if the source is open we can easily make a version that bypasses the onl…

How would you define it if: - the DRM/delivery software is open source - the game payload is sent to you encrypted using the public key of a secure enclave on your computer - while the game runs all its memory is symmetrically encrypted (by your own CPU) using a key private to that secure enclave. It is only decrypted in the CPU's cache lines, which are flushed when the core runs anything other than the game (even OS…

[dead]
Post reply on HN