IDK, try it and find out? I run it native and haven’t had any issues, and my main concern running it in a FlatPak would be access to system devices like controllers and whatnot. If I ever run into issues, I’ll probably give the FlatPak a shot, but I don’t have a good reason to at the moment.
You can do this with the Flatpak version of Steam, but you have to give it access to the disks.
Flatseal is the easiest way to do this.
Open Flatseal
select Steam
scroll down to the “Filesystem” section
click on the + icon on the “Other files” area
either put in the full path, or use something like “/run/media” to give it access to all user-mounted storage devices (this value may vary depending on how the disk is mounted)
Restart Steam (if it was running). You should be able to access additional devices.
Same here. Radeon open source drivers. VR is working, too (HTC). Most oft the time what I need to find out is the correct Proton Version (Took me a bit oft time to geht Cyberpunk running). Other than that no problems at all.
I have ran the flatpak version for a long time without any issues for games from Steam. How ever if you want to “add none Steam games to Steam” that are also flatpaks you need to add more permissions to the sandbox. You might want to do this in certain cases for example you want to utilize Steam Input for a flatpak game/emulator for better controller support.
I just refunded the stanley parable because I couldn’t easily get it to work on my arch system. Though I suspect the fault lies somewhere between hyprland and wayland, as I tried all other fixes I could dig up, but I can’t easily get X on my system to test, so I just ended up requesting a refund.
Apart from that things have just worked. Funny how a title that is supposed to run native is one that gave me a headache (proton also just flat out refused to launch it).
This can’t be true. If you are on Arch, this should be very easy to do. I’ve had a backup i3 session available on my system for years alongside sway. It should be as easy as installing an X based DE and then selecting that session from the display manager
Im actually not sure if this is important, but I know hyprland has a different xdg portal, so there is that, then I have a dual monitor setup with different refresh rates and last I checked X was a pita to set up for that (to work correctly).
Like could I actually just install some Xorg DE / WM and send it? Possibly would be as easy as grabbing something from AUR / pacman and relogging, but doing it right from hyprland and with my specific setup is dubious. Then there is the question of actually having to use Xorg to play one specific game.
In the end it is more effort than I am willing to put into troubleshooting a game I will probably not actually finish.
For anyone interested: I've been using a large 144Hz 2560x1440 monitor next to a pair of 60Hz 1920x1080 ones with only a touch of xrandr (one line per screen) to make the positioning comfortable for me (just as a matter of preference, due to monitor height differences).
Idunno when this person last checked (and seemingly then set a permanent opinion, as many do for some reason) but getting X to handle differing refresh rates in multi-monitor setups is trivial now, unless I'm missing something.
League of Legends does work but it's painful. I use an AUR package called leagueoflegends-git which was the only way I could get it to work on my setup.
https://leagueoflinux.org/ has been invaluable. It used to be a subreddit but it's been made private since the API debacle.
Well, painful for me. I tried Lutris, Bottles and native Wine and none worked. I played around with wine-lol for a bit too but the AUR package was the one that got it working.
Yeah, I used Lutris a couple years ago and it worked pretty well. I don’t like League much, but it worked well enough for my friend to play a few games with me to show me how to play.
The issue isn’t even that BattlEye doesn’t work under Linux, because it does. It’s that a lot of studios that use it, namely Bungie and Ubisoft, explicitly refuse to enable support for it. Somehow they allowed Division 2 to run, but even then it only appears to be the Steam version, because my Uplay copy does not have the necessary files in the bundle
This might be a stupid question but is it possible to copy the files you need to your Uplay install? It doesn't guarantee that the game will use them but worth a try I suppose.
No, I don’t. I got it on a whim through Epic, when it was on like a 90% sale, and that’s the only game I own there, but it’s installed through Uplay itself. The reason I know about the files, is because they appear in a steamdb manifest
Theoretically would you’ve said could work, but since we’re talking about modifying critical files, they might just slap me with a ban, and I don’t really feel like doing that. They probably check the hashes of the included bundle immediately
Understandable. I'm not sure how strict Uplay is about the files but from my experience with the bot in R6 Siege, it probably hands out bans like chocolate in Halloween.
I was in same situation with Star Wars: Squadrons i got it on Origin and some files for anti cheat were missing that steam version of game had… I found online missing file online copy and paste and game worked
What I’ve heard is that they don’t think that it’s a big enough market to have to fix bugs that might happen only on linux and such, so they just don’t allow is to play.
It’d be nice, but from what I see most devs against this suggest Linux gamers are a bunch of dirty hackers and it’s somehow much easier to cheat there.
They just conveniently forget that Valve offered to fix any bugs themselves that are specific to Linux/Proton…
Most threads I've seen lately about gaming on Linux have explicitly been about sharing config tips for pirated repacks. I'm not saying it's necessarily representative, but there is the impression that a good number of the already small Linux footprint is pirating the games, so why would a dev make that easier? I get that too some extent some folks might buy the game, ruin into issues, and then try a repack. But it feels like there is a sizable community that just pirates the game.
The discussion is about anti-cheat, so piracy is not relevant here.
And no, there isn’t that impression.
Statistics from Humble Bundles and such have always shown that Linux gamers are willing to pay more than any other platform.
Plenty of games with anticheat have been pirated, like elden ring. I'm just saying that some devs might view not working on Linux as a feature not a bug, if they have the perception that a high proportion of Linux users are using repacks. There are some extremely vocal minorities in the FOSS world that could create that impression.
In any case, nice to see this dev look into the issue. I have my oldest boys using steam deck so the more compatibility the better.
I’m just saying that some devs might view not working on Linux as a feature not a bug
Those devs are exactly the reason why we’d pirate their game with anti-cheats. Not only because the pirated version may work compared to the official one but also, in this case, as a deserved fuck you to the developer.
I’m someone who typically endorses piracy (with the caveat that you should support the people who make the content if you can afford to) yet I will also be the first to straight up buy or not play a game rather than pirating it if it works well on Linux because I think it should be rewarded. And according to Humble Bundle it would seem Linux users pay more than others, so if a specific game is pirated a lot more than acerage on linux then perhaps the problem isn’t the Linux community but the game itself and a good dev would see that and fix their game.
Without mentioning that piracy, as stated by Nintendo and other companies, can actually sometimes help a game (for example if said pirate then talks about the game to others who may buy it, or if they then buy it after trying it and liking it).
Either way this is about anti-cheat, not DRM and anti-piracy. And even more-so by automatically excluding every Linux user you’re also excluding those that would have paid, that’s literally shooting yourself in the foot as pirates wouldn’t have paid you regardless (of course with exceptions) but some users would have and you stopped them from doing that with your move.
Maybe the pirated version does work on linux while the official doesn’t. For example if you wnat to play Rust on linux you have to play on non-EAC servers which are a lot more common on the cracked versions (for anyone trying to run official version of Rust, you can still connect to cracked servers that have their own Anti-Cheat, like any ArabRust server for example)
Right, I get using a cracked version for compatibility, and tried to convey that on my first post. I've done the same thing, especially with older games.
I am genuinely curious how anti-cheat works on an open source OS. I don’t know a whole lot about how it works to be honest, but is there no problem with cheaters being able to manipulate the entire stack down to the kernel level?
Like I’m aware cheaters can decompile code so closed source isn’t necessarily that much better. Did I just answer my own question or is there more to it?
This is why client-side anti-cheat is a terrible idea. It gives you the illusion of control, but really it doesn’t prevent a motivated party from cheating, and it opens up everyone else to kernel-level vulnerabilities when the anti-cheat software inevitably has a bug.
Client side anti-cheat should merely discourage low effort attacks, and the real cheat detection should always be server side looking at patterns of behavior. Unfortunately, it’s a lot easier to reach for client side anti-cheat than build an effective server side anti-cheat.
This is a really good answer, thanks! I like to imagine what a fully open-source future would look like and I imagine server-side anti cheat is the solution.
I don’t think popular games will ever be fully open source, but our operating systems could be.
I have very little proprietary software on my system outside of games, and it’s mostly limited to a handful of firmware blobs (e.g. GPU and WiFi firmware, CPU microcode, etc), with the clear exception bring browser DRM for streaming services. Everything proprietary on my system is sandboxed in some way, so I’m reasonably protected from most of that nonsense, but it’s still there and probably always will be.
Having proprietary software isn’t the issue IMO, as long as I can sandbox it. I can’t sandbox kernel level anti-cheat, so I’m never going to install a game that requires it. That’s my line in the sand.
Mostly profit motive. Most open source software is free, mostly because it’s really hard to profit from something anyone can build for free. As soon as the source is released, someone will make a free build of it available and undercut the devs.
Devs, artists, etc all need to eat, so the game needs to be profitable enough to cover that.
It’s not like games can’t be open source, and I’ve played plenty that are, they just won’t likely be profitable.
I aim to one day make money via a pateron model like Godot: getting paid before development… that requires a good reputation via what I have already made. If paid enough at that point then it doesn’t matter if I don’t get more at distribution. Before that hopefully some donate (⌒_⌒;)
I also hope gamers one day have their equivalent of the recent Unity devs moment. See the potential for abuse of power and no longer tolerate untrustworthy proprietary options - thus moving profit motivate to open source/free software.
I also want to make games and distribute them for free. I want to follow something like the Dwarf Fortress model where development is funded by fans and I build it because I love it. However, I’m not at the point of my life where I can do that, so for now it’s a motivator for me to retire early.
But that model is highly unlikely to become the most common distribution method for games, just like it isn’t the most common distribution method for other end user software. People just don’t donate nearly as much as they’re willing to pay for equivalent software. Building software is expensive, so if you’re in it to make back your investment, propriety software is the way to go.
Devs, artists, etc all need to eat, so the game needs to be profitable enough to cover that.
And yet the devs, artists, etc of FOSS programs also need to eat, and the software is still FOSS.
(Sure we should all be donating, or rather, they should get their income from our taxes since oftentimes they literally are the backbone of the world, but that’s one more convo to the pile)
But that’s not at all how things work. Most FOSS devs do it as a hobby or as part of a day job working on proprietary software. Very few FOSS projects employ full time developers, and for those that do, it’s rarely a majority of the code changes for the project.
But let’s say we somehow convince governments to fund FOSS development, they’re not going to want to fund game development, they’ll fund one Linux distro and the software needed to fill government needs.
If a large game engine like Unreal Engine suddenly switched to the GPL, game devs wouldn’t touch it with a10 foot pole. They’d either develop their own engine, switch to a different proprietary engine, or use something like Godot where they can keep their project under a proprietary license.
One thing that I hope becomes more common is open source game code + proprietary art, sound and narrative. Game devs, artists, writers, etc deserve to get paid for their work, and we deserve to know what’s running on our computers. The more game devs use open source engines, the closer we get.
Maybe it’s because I am an amateur dev and not just a user but I like the freedom with assess that are creative commons and am put off when an open source game uses (edit) proprietary assests. Don’t see why they can’t get paid the same way open source dev would.
I don’t think we need open source games, we just need to be able to sandbox them so they don’t cause security or privacy issues. As long as they don’t need control over the kernel, I can containerize them and only give access to the things they need.
Not all anti-cheats are kernel-level though, only the most invasive ones are. BattlEye, the one used in this game, is not one of them, though I don’t know the specifics of how it works.
Sure, and I don’t have issues with those, provided they are happy living in a sandbox. I think clientside anti-cheat is stupid for other reasons, but I won’t actively avoid a game just because it has it, provided I can separate it from the rest of my system.
Firstly, not all code executed on an open source OS needs to be open source. For example: Epic Anti-Cheat, which comes with a Linux-compatible mode, is fully closed source. So right off the bat we’re going to put to bed the notion that somehow the platform of choice makes it easier for bad actors to pull apart and examine anticheat software.
Secondly, yes, there is a problem with cheaters being able to hide from anticheats on Linux. This is because on Windows it’s relatively easy to run kernel-level code via drivers – this is why most anticheats require admin permission to install a monitoring driver before the game will run. The anticheat is effectively rootkitting your system in order to circumvent other rootkits that may be concealing epic cheatz.
On GNU/Linux, almost all device drivers come prepackaged in the Linux kernel, so there’s no direct equivalent to the Windows approach of allowing users to install third-party code into the most protected rings of the OS. It’s still possible through the use of kernel modules (see NVIDIA drivers), but as evidenced by how annoying it is to use NVIDIA devices on Linux, this is a huge PITA for both the developer & the user to deal with.
So that’s the rub. On Linux, anticheats just have to trust that the kernel isn’t lying. This has been a perpetual thorn in the side of developers like Google, who’d really really like it if they could prove beyond a shadow of a doubt that a given Android device is not rooted (see SafetyNet). Google’s solution to this has been to introduce hardware-backed attestation – basically a special hardware chip on the device that can prove that the kernel software has not been tainted in any way.
It’s also true that the ease with which a program can interact with kernel level drivers opens up a whole host of potential exploits including but not limited to recording all internet traffic, all keystrokes, listing all files & programs, accessing memory of other programs and more. AAA client-side anticheats require some pretty incredible trust in the vendor to not be either evil or incompetent.
Right so on a technical level it is actually harder to do client side anti-cheat?
Thanks for the information. That hardware backed attestation reminds me of Little Brother by Cory Doctorow, where hardware DRM was introduced and then forcibly deprecated when it was found to be vulnerable… so of course the vulnerable hardware was now worthless except on the black market where it was worthwhile to pirates because it was known to be already cracked.
That’s a good point. I realise my question partly plays into a misconception about the security of closed source software, that it’s somehow harder to mess with.
I mean people are training neural nets to look at the screen and aimbot by modifying the mouse inputs, which is just an impossible thing to detect.
I want to be optimistic, bit honestly this to me reads like the non-commital “thanks for your concern, we’ll look into it” consumer service style non-answer.
I hope it ends up somewhere, but I can also see it remaining in their ticketing system for eternity.
I think the Steam Deck is a platform that devs are aware of, and I’m sure they don’t want to alienate that segment of their sales. They also want to avoid negative reviews.BattlEye is also supported in other games on Linux, including native versions, so it shouldn’t be a big deal to ensure its functionality.
I’ve seen this argument pop up but I’m confused with technical details on how it would work. Wouldn’t the client still need to download the game? Modifying the game files is a vector for attack. If it’s fully online on their servers then it would be pretty slow wouldn’t it?
The client is nothing but a display. All it downloads is vid and all it up loads is control. The only actual issue is potential for lag. ag is solvable by designing with it in mind.
Think about things like stadia. If they are viable so is actually running the game on the server. This way all the activity is server side and everything coming from the client is validated.
The actual issue is that the game servers and networking would be more expensive. And that is the real reason they do it with DRM, it is cheaper for them. Your experience is not important to them.
The lag issue is really one of design and cheap server side infrastructure. A shooter would use a time stamp to allow position validation for when the shot was fired. Simply reduce the micro management and you've resolved most of it to start with.
It is only slow if the infrastructure is crap. And you are complaining about the current state and not what would happen. Very, very few games have been released over the past decade with LAN play and the no online required is only a bit more. You objections are very hollow.
And which company is currently about to release that for the first time? See this is about DRM on games and none of the companies are paying to put that on antiques. I can still roll my Mechwarrior Mercenaries 2 server as well, but that also isn't relevant to this thread.
linux_gaming
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.