Quoting: Liam Dawe

Quoting: BlackBloodRumA minor note on your instructions; for KDE users the Deck method would work identical for a desktop user, they're not Deck specific. It may be better to list "manual" and "automatic" install perhaps. It seems a bit odd to separate the deck instructions, when realistically they apply to desktop just as much. Both KDE Discover and Gnome's equivalent (whose name escapes me right now) have Flatpak integration[1]. So the installation should be the same for both, if installing ProtonUp-Qt using graphical tools. :smile:

Not a criticism, just an observation. I mean no offence. :happy:

[1] Unless they use Gentoo like me and deliberately didn't install KDE Discover on their KDE :tongue:

I may rework it, but it's not as simple as you think.

Ubuntu uses its own store, which doesn't integrate Flatpak but it does for Snap / deb. Then what about Budgie desktop? Cinnamon? Xfce? Lots of different desktops on Linux remember.

Edit: did an edit that I think works for everyone now.

You do raise a valid point here, I had not considered that. Although, I feel that users of more niche desktops most likely already know how to install flatpaks :smile:.

As for Ubuntu, why doesn't that surprise me? I thought they at least would have that. But alas, not. I haven't used it in a very, very long time. But I do know other distros such as Fedora, SUSE, Arch, Gentoo, Debian, etc. Support flatpaks just fine :-).

Anyway, my apologies! I had not fully considered all use cases. I feel the most recent revision of your article covers everything just fine now, in any case :-).

View this comment - View article - View full comments

A minor note on your instructions; for KDE users the Deck method would work identical for a desktop user, they're not Deck specific. It may be better to list "manual" and "automatic" install perhaps. It seems a bit odd to separate the deck instructions, when realistically they apply to desktop just as much. Both KDE Discover and Gnome's equivalent (whose name escapes me right now) have Flatpak integration[1]. So the installation should be the same for both, if installing ProtonUp-Qt using graphical tools. :smile:

Not a criticism, just an observation. I mean no offence. :happy:

[1] Unless they use Gentoo like me and deliberately didn't install KDE Discover on their KDE :tongue:

View this comment - View article - View full comments

Quoting: Jmsnz

Quoting: elgatilI think the result of MacOS gaming being thrown under the bus due to metal is just collateral damage of their strategy with iOS. Most mobile devs develop for iOS and then they port to Android, best case scenario both versions are developed in parallel. Metal is just putting sticks in the wheel to that situation,

With iOS they have the majority of the (paying) users, with MacOS they have a niche audience and it seems they do not mind being mistreated.

The death of old macOS games on steam had nothing to do with metal. It was the loss of 32bit support that did that.

Yup. I understand why they wanted to drop 32-bit support. But they could have added some kind of compatibility layer, even if it meant something like Wine or sandboxed libraries or such. They could have handled the whole thing better instead of just "as of this release, 32-bit is gone and there's nothing you can do about it.".

I really felt that was a massive FU to their customer base.

(For those about to say "But some Linux distros dropped 32-bit!", they did, but there are other distros which still have the support, users still have options available to them. That and often, you can still go put the 32-bit libs back in.)

View this comment - View article - View full comments

Quoting: scaine

Quoting: Guest

Quoting: scaine

Quoting: Guest

Quoting: scaine

Quoting: M@GOidFingers crossed it will come too late to be included in Kubuntu 24.04 LTS. I had nothing against new things, but in my past experience, big new versions of KDE are to buggy to be used on a production system, and the last thing a LTS release needs is bleeding edge software.

Conversely, if they don't put Plasma 6 into the LTS, the "desirability" of that LTS decreases significantly outside of hard production environments. Also, the older environment becomes a chain around the Kubuntu team's neck as they're still putting out fires on Plasma 5 five years after everyone has jumped onto Plasma 6 (or seven, by the end of that LTS's life).

I'm on the Kubuntu right now and if there isn't a simple way to get Plasma 6 on there, I'll be jumping distro. Again. Argh!! :grin:

Outside of hard production environments there is not much reason to use fixed release distributions anyway. LTS are made specifically for long term productions. If you want new stuff, hop on a rolling distribution.

I use LTS, with PPAs for updates because I don't want to update my OS every 8 months. Works pretty well. Rolling distos are pretty cool for new stuff, but you get reams of updates every day which is a bit tedious. Also, when large upgrades happen, such as the move from one version of python to another, you often get breakage which is a pain to handle in rolling distros.

Honestly, I haven't found the "perfect" model yet.

Manjaro gets updates every few weeks, which is totally not tedious.

You know, as I replied earlier, I actually thought of Manjaro. But the dev team behind that distro has faced a few controversies in the past. Then, on the two occasions I tried it anyway, I ran into heaps of little issues. It was death by papercut. It obviously works for a heap of folk, given that it's the third-most popular distro on the GOL stats. But it's not for me.

To be honest, rolling is great for people who want that. But there's zero reason to shun versioned distros. Particularly if that's what someone wants from their OS.

FOSS is about freedom, part of that freedom is freedom of choice. So go ahead and continue using whatever distro you enjoy, because if it does the job and fits you well, then to be realistic there's very little reason to change it :-).

View this comment - View article - View full comments

I never did get why Apple decided to ignore Vulkan and keep only Metal. :neutral:

I understand technically, Metal came first, but they could have added Vulkan later on. I mean, I like heavy metal as much as the next guy, but I can't help but feel they kind of shot themselves in the foot with that one.

But then, we're talking about Apple here, who intentionally killed the majority of MacOS native Steam games on their OS (they won't run on the latest OSX due to Apple's changes).

View this comment - View article - View full comments

Quoting: Mountain ManMeanwhile, the pirates will continue to download the DRM free offline version and won't have to put up with any of the nonsense paying customers are subjected to.

This could well be true. :whistle:

View this comment - View article - View full comments

It's great to see progress, and have some dates[1]. :grin:

[1] As in release time.

View this comment - View article - View full comments

You see folks, this is why you don't drink and github. :angry:

View this comment - View article - View full comments

Quoting: denyasisThanks for the info. Might I tee you up another question(s)? Hope is not too silly.

There's no such thing as silly questions, there are only questions.

Quoting: denyasisFor the nearly 2 decades I've toyes with Linux the mantra has always been "ppl won't target Linux because it's too small so malware won't work!

Now, I truly mean no offense, but the beginning of your post reminds me of that. Why would it just look for Windows directory? Why not just go up a level or two or simply run from the directory it's currently in?

I've heard the same thing, and I disagree with the idea that the OS and market share is too small to be targeted. It was not the point I was trying to make, but rather, that a malware designed for Windows will most likely look for Windows related resources.

Ironically, in our quest to make Games and other applications more compatible with Linux, we also make malware more compatible with Linux.

Quoting: denyasisFor the sake of argument here, let's presume a Linux build of a Steam game was infected... Why would we presume it would look for Windows stuff? It's already running attached to a Linux script or executable in Linux environment, right?

That's a different issue altogether, if it's a Linux native build then it's probably a Linux native malware. To protect against such a threat would require further hardening. In that case I would strongly recommend SELinux, ideally on a distro that has it enabled by default. I say that since on a distribution which has it enabled by default, it is far easier to setup SELinux than one that doesn't, so you could simply tweak it rather than configure the whole thing.

There is AppArmor as an alternative. Otherwise, if neither of those are suitable then there's always Firejail.

Quoting: denyasisI see your point about Proton and Wine making things more difficult, but I do have a question about that. I know they still seem to keep Z: as the rest of the file system outside the prefix. Why would a Windows malware not look for other drives? You're right, it depends on what it's trying to do, but I can say my limited workplace experience is all in Microsoft shops and they all use network drives heavily. I'd expect a ransomware or something similar to look for stuff outside C: right away, right?

That's something more people need to ask. It's true, if the ransomware looks beyond C:\ it will most certainly find Z:\ and if it does, it will see your root directory (/). But that's also why I mentioned it depends on what it is looking for. A ransomware will almost certainly try to get everything it can find, on any drive. So you'd be hosed in that case. On the other hand, a malware which tries to steal login credentials will probably get lost in Z if it's not aware of how Linux works.

But this is a key misconception with Wine and Proton in general: Wine (Proton) is not a sandbox, it never tried to be, it never was. It never will be.

On its own wine can do very little to protect your system from the malware, because it's simply not trying. That's not its job. However, that doesn't mean you can't bolt on other things to your Linux to protect against things ran inside it.

This is why the sandbox, or limitation of file access by other means is important here. For example, if you install flatpak steam, configure the permissions to only allow specific directories, you'll find that proton's Z:\ will simply lead them to files within the sandbox, with no further access to the steam (So your real root (/) cannot be accessed).

This sandbox would be active whether you are using the malware within proton, or the malware as a native application. Protection from both. Neither can access your root (/). That's why I heavily recommend the flatpak to new users, just for that extra bit of protection, assuming you don't have "All system files" filesystem access enabled, I really wish developers would stop enabling that in flatpaks.

Quoting: denyasisLast last question.... Even with everything sandboxed, a malware (say some sort of DDos bot), could just sit in the sandbox and do it's thing? We'd still need an antivirus or someway to detect it being there, right?

Yes and no. Assuming for the moment that the malware is trapped entirely within the sandbox, then it will start and end with that sandbox. So for example, if you have a Windows malware that is running within proton, when you click "Play" on a game, it will probably launch with the game (it sees this as a system boot). When you exit the game, if the malware is attempting to run in the background then you'll notice that Steam's button didn't return to "Play" after the game exited. It's worth asking yourself why that may be. The malware will keep the prefix "awake" so to speak, so you, and steam, will notice the prefix hasn't exited.

For a native malware, it may be a little trickier. Still assuming it didn't escape the sandbox entirely, it is possible it forked another process which the Steam client is unaware of, in this case your game would appear to have ended, and the button will return to the green "Play".

However, that process too will end once the flatpak is closed entirely. For example, executing:

flatpak kill com.valvesoftware.Steam

Would immediately stop any/all malware running within the sandbox, along with Steam itself of course.

There is one thing that should be mentioned however, the sandbox covers Steam as a whole, so that means it would theoretically be possible for a malware to spread itself to other games, and the sandbox as a whole. The sandbox does not protect on a per-game basis, so all games (and therefore malware) are able to see each others files.

Since everything is happening within the Sandbox, you will probably notice rogue or strange processes within your process monitor, linked to the sandbox. It does mean however, a ransomware could encrypt your entire Steam flatpak installation, all games everything, but that's so far as it would go.

Should you install anti-virus? It's not strictly necessary so long as you take other steps to protect yourself such as sandboxing. With that said, I would suggest having ClamAV or such installed in general, if only just to do occasional checks and to verify things you've downloaded are clean before you share them onwards.

There's also a couple of online services which can check on a per-file basis if you wish.

But overall, your safest option is to simply use common sense. Don't download from dodgy websites, that video isn't that important.

The biggest threat however is not Steam, Steam is one of the safer options. The biggest threat is games from Itch.io, since in many cases files are simply not checked before you download them, or you may be pushed to third party websites entirely to download.

Quoting: denyasisThanks for answering my questions and having the patience to deal with stupid questions!!

There's no such thing as stupid questions, there are only questions.

Linux is not immune to security issues, it never has been. But it does give you some really good options to protect yourself, should you feel the need. In all honesty with the Linux user base growing, the risk of more Linux malware showing up only grows stronger.

(And when dealing with proprietary software? There is a need!)

Quoting: Nic264

Quoting: BlackBloodRumIt is possible the malware has been trained to handle Linux, in which case it will try to get access to your home directory. Worst case here is your home directory gets hosed, and data which your user has permission to modify is altered, which is fairly minor.

Worst case is rather that it uploads your ~/.ssh, ~/.mozilla and ~/.thunderbird to some remote server.
I would not call that “fairly minor” either way, what is more valuable on your computer than your data?

That's a fair point, but you should aim to minimize damage. In my own case, if the malware uploaded those three directories, they would get:

~/.mozilla - not found
~/.thunderbird - not found
~/.ssh - Keys which require a physical yubikey to be pressed to unlock.

View this comment - View article - View full comments

We have reached Extend.

View this comment - View article - View full comments