If you insist upon saying one store is more virtuous than the other… okay? I personally don’t like defending companies but you do you.

Could you please not put words into my mouth? Neither is “virtuous” and I am not defending them. Let’s stick to the facts instead. It’s clear that EGS is being actively hostile towards Linux, while GOG is merely negligent. EGS actively removed Linux support from previously supported games on at least one occasion (Rocket League).

Not nearly the same degree. GOG sells actual Linux games with no 3rd party software necessary to play them. The same cannot be said about EGS, one simply cannot launch an EGS game in an officially supported way.

FOUL TARNISHED!

They have full legal rights to ban you for farting when the minute hand and hour hand aligned. This changes nothing in terms of what they “can” do. It’s rather their public announcement about what they “will” do. If they really wanted to ban you for silly reasons, they don’t even need these silly reasons, they can just ban you and are fully within their legal rights to do so.

Just like any game ever sold on a CD.

How does an offline installer from GOG differ from the offline installer provided on a CD/DVD?

This is equally true for almost any game ever sold, including physical ones. You only ever own a license that specifies what you can and cannot do with the game. The difference is in what this license is tied to, for example either a physical copy of a given game or an account that can be remotely deactivated taking away all your games. In GOG’s case once you grab the installer, the game license cannot be easily forcibly revoked, just as with the physical copy.

Which features do you mean? Not disagreeing with you, I’m just curious.

Either multiple different keychains or even you can have no keychain-like application in your system at all.

The WiFi passwords are usually stored in /etc/NetworkManager as plain files. Granted, they are not accessible directly by non-root users as they are being managed by the NetworkManager daemon, but there is nothing generic for such a thing. Signal rolling a similar daemon for itself would be an overkill. The big desktop environments (GNOME, KDE…) usually have their own keychain-like programs that the programs provided by these environments use, but that only solves this problem for the users of these specific environments.

To me it’s perfectly expected the Signal encryption keys are readable by my user account.

There is no single keychain on Linux, and supposedly on Windows too. Signal would need to either support a few dozens of password managers or require a specific one, both options terrible in their own way. This isn’t something that can be done without making broad assumptions about the user’s system.

An int& reference is just as much of a variable as int* const would be (a const pointer to a non-const int). “Variable” might be a misnomer here, but it takes just as much memory as any other pointer.

never mind, I looked it up. It’s a “reference” instead of a pointer. Similar, but unlike a pointer it doesn’t create a distinct variable in memory of its own.

I’m almost sure it does create a distinct variable in memory. Internally it’s still a pointer, specifically a const pointer (not to be confused with a pointer to a const value; it’s the address that does not change). Think about it as a pointer that is only ever dereferenced and never used as a pointer. So yes, like the other commenter said, like an alias.

I’m truly confused about what people expected.

Let’s redistribute the farlands!