Quoting: TurkeysteaksServer side anticheat is unfortunately a dream (Poor Counter Strike), and cheats only keep getting more sophisticated. Is this problem solvable?

You hit the nail on the head. The problem is not solvable as long as players have access to the hardware.... and even then that likely won't stop it. This is the same problem we see in the InfoSec world. The more sophisticated counters there are to Cheats (and Malware), the more sophisticated workarounds will exist. It's not winnable and the more complex the Anti-Cheat gets, the more complex the Cheats will find be.... and this doesn't even include how OS vendors really want to start isolating applications from the system itself. Besides Docker/Flatpak/Snap on Linux - Windows, MacOS, iOS, and Android all have ways to sandbox applications so they don't have direct access to the system.... it's just that none of these systems have, as of yet, been enforced on developers.

It's like Nintendo/Sony/Microsoft trying to stop physical hacks on their consoles. You simply cannot short of creating legal gates to even learning Electronic, Mechanical, Software, Systems, Network, etc Engineering skills.... Kind of like how some Law Enforcement want to hamstring Encryption or make it illegal without realizing that it's just Mathematics... you know that thing you learn in school?

View this comment - View article - View full comments

Quoting: CyrilI see... but it's still difficult for me to have a clear view about it, like a concrete example (but it's OK), as your explanations are very general for me (and it's the first time I read that kind of stance so I'm surprised).

The point is that when Game Devs are used to building games for a single target on Windows or Consoles, then try to move to Linux where even in the Desktop space, things are not static nor consistent like they are on Windows or Consoles. Most larger studios are not well suited with current experience to build and maintain games for every major popular Linux distro and indie devs definitely don't for more complex games like this.... and definitely not while they are also trying to solve infrastructure and network stability issues.

The problem still comes down to an assumption that all game development is the same/similar across all platforms. This is why so many studios stumble when building a game on Unity or Unreal and think "We'll just click the build Linux button" and it'll work.

This is also why Proton has worked so well as it creates a singular target for developers and they don't have to maintain it. Despite what many think, it is very much a "Native API" for that's what it is. It's not trying to mimic hardware or software to the level that something like DOSBox or Yuzu do, but instead actually building an API. As I said elsewhere, if Proton, or its components, are not native, than no API of any kind is "native".... including Linux's own APIs.

View this comment - View article - View full comments

Quoting: CyrilNeovim is available in Arch-based repos at 0.10.1 version.

That's not an answer. Arch-based distros are not great for every person. I'm not complaining as I've found my way around the problem. My point is that System Packages are just that, they are for the System. The distro maintainers first and foremost are building the System packages based on what is needed to run the OS, NOT based on what users may/may not need.

Quoting: CyrilI don't like to be that guy but... if you complain that your distro doesn't have the software you need in the repos (or the good version etc.), maybe that distro is just not for you.

I mean, you have to chose between "stable" and "very recent software", you can't have both. Because the Windows way, or Flatpak way, etc. have their own issues too...

"but far slower than most server applications or CLI tools need these days", I'm a bit dubious about this, or don't know what you have in mind when you say that, because precisely the vast majority of Linux servers run LTS distros (Debian, Ubuntu...) and it seems to be just fine. I didn't hear anybody, in my circle, complain about that.

Tell me if I'm wrong or If I didn't understand you correctly.

I've been in tech for about 15 years (longer if you count my volunteer work for orgs). It's never that simple, especially in a workplace where what distro you use must be approved by Legal/Security/Mgmt/etc or if you're running things in a cloud/service provider that either controls the underlying OS or the distro options. For example, the only options for OS on GKE is either Google Container OS or Ubuntu. That's it. They are updated and maintained by Google and we don't control anything that's installed. And again, as an Engineer, I don't get to make the decisions as to what cloud platform to use or not use. Many times the decision was made long before I joined.

Finally, "Not a distro for you" is irrelevant when you are building software meant to run on all major distros. Especially for Server or CLI tools. Sometimes, depending on the project or contribution, you are limited with language choice. For something like Rust or Go, you can usually just build a binary that contains everything needed to run the tool/server, unless it reaches out to a shared C library or uses a Foreign Function Interface (FFI) then you have to make sure that either the system contains the correct version of the library to run. With Server Distros being RHEL/OEL/CentOS Stream/Rocky, Ubuntu, Debian, and SUSE (major ones), none of those distros run the same versions of C, Python, Ruby, Perl, PHP, etc..... which usually means we have to find a repo ourselves, build those languages/libraries from source (pain to manage and removes the benefit of packages managers), package the application with EVERYTHING that it needs, or build a container to run it all.

Usually for an Open Source (or Commercial) software product, this means having to build an RPM for EL-based distros, a DEB for Ubuntu Server, and a Container at least. Sometimes a SUSE RPM and/or a debian-specific DEB package (if the Ubuntu one doesn't work). This is near impossible for most Open Source communities that aren't funded by one or more companies and have to be continually updated due to the rate at which bugs and security vulns are discovered.

So, no, "Not the distro for you" doesn't work for what I'm trying to describe as we usually aren't building for just our laptops.

View this comment - View article - View full comments

Quoting: chr

Quoting: EagleDelta

Quoting: CyrilTL;DR: so it's much of an Ubuntu problem than anything else...

No, this is an issue with any LTS-style non-rolling release distros. RHEL/CentOS/Rocky Linux style distros are even worse. In most of my jobs over the last 5-7 years, the system packages are only used now to run the system itself. Everything else we need to run these days is largely built in Go or Rust so we can just deploy a binary OR (more often) it's run in Docker/Kubernetes or a platform like Heroku where we don't have to deal with the fact that distros simply don't keep things up to date enough for the features that we need many times. Things like unable to use libraries that solve performance or security issues simply aren't available on the backported versions of Ruby, Perl, even Python sometimes.

EDIT: I just realized I wasn't clear in what I am saying here. I don't necessarily think that every distro should be rolling release. My point is that system packages are best for running the system, but not always for running applications these days. While I can use whatever Tmux is in the repos for example, I cannot use whatever version of Neovim is provided as my config requires at least version 0.10.0 which I don't believe is in any repos yet. And as for games, if they are primarily multiplayer, like Xonotic, than Flatpak is the best as you can't play with other players that aren't on the same version as you.... hence the limits of mostly static system packages.

Perhaps EagleDelta is talking more about the server/CLI space and Purple Library Guy about GUI apps distributed by a non-rolling distro?

I ended up on a very long tangent addressing The Purple Guy's comments about System Libraries being good for Open Source Software and how, from my experience, that's not the case anymore.

But it does go back to the general issue we see with Game Devs. Many of them are used to relying on Windows system features/libraries built into the OS or Ecosystem, whereas in the Linux Ecosystem, those change more frequently than in Windows, but far slower than most server applications or CLI tools need these days.

View this comment - View article - View full comments

Quoting: CyrilTL;DR: so it's much of an Ubuntu problem than anything else...

No, this is an issue with any LTS-style non-rolling release distros. RHEL/CentOS/Rocky Linux style distros are even worse. In most of my jobs over the last 5-7 years, the system packages are only used now to run the system itself. Everything else we need to run these days is largely built in Go or Rust so we can just deploy a binary OR (more often) it's run in Docker/Kubernetes or a platform like Heroku where we don't have to deal with the fact that distros simply don't keep things up to date enough for the features that we need many times. Things like unable to use libraries that solve performance or security issues simply aren't available on the backported versions of Ruby, Perl, even Python sometimes.

EDIT: I just realized I wasn't clear in what I am saying here. I don't necessarily think that every distro should be rolling release. My point is that system packages are best for running the system, but not always for running applications these days. While I can use whatever Tmux is in the repos for example, I cannot use whatever version of Neovim is provided as my config requires at least version 0.10.0 which I don't believe is in any repos yet. And as for games, if they are primarily multiplayer, like Xonotic, than Flatpak is the best as you can't play with other players that aren't on the same version as you.... hence the limits of mostly static system packages.

View this comment - View article - View full comments

Quoting: Purple Library GuyIt's not optimal for open source software that's part of the general Linux software ecosystem; the expectation is that that stuff will keep on getting updated more or less forever and if it keeps upgrading to the latest libraries you'll get the best function, security and so on, and you avoid duplication by using system libraries. It's all kind of messy but has a lot of advantages, and it's pretty clear from the history of Linux that it can be made to work.

I can't speak to others experiences, but I can directly say, as someone who's been a part of an Open Source community for over a decade, having to build software (especially server software) using only libraries compatible with those packaged in the system. Namely, building software in C, Python, Ruby, Perl, etc - it's no feasible as in most cases, the communities responsible for those languages are not going to help you because what the distro packaged they took End Of Life anywhere from a year to a decade ago (depending on distro). Which leads back to packaging the tools together. It's not usually as bad with Python, but with other languages? There's a reason things like Puppet and Chef's official upstream Open Source repos (YUM, Apt, etc) all package Ruby within the tools.

Case in point - Ubuntu/Pop!_OS 22.04 ships with Puppet 5.5.22, which was End of Life in October of 2020..... 18 months before the LTS distro was even released. If you have issues with that version, The Puppet OSS Project, Puppet Company, nor the Vox Pupuli Community (which I'm a part of) will support you. None of them have the bandwidth to support stuff that old. So, no, it's not feasible for Open Source software either to ship only with System Libraries. One of the huge reasons I've seen Go and Rust tools take off in the CLI is because they can be compiled and ships many times as a single binary not reliant on anything in the system. They just work.

View this comment - View article - View full comments

Quoting: DesumNative Linux can be a hassle to support at the best of times. And it isn't exactly all roses for users either. Who here hasn't had to perform dependency surgery on a GOG or Humble Bundle native Linux game fat some point? That is MUCH less of an issue with Proton.

Until Linux can further mitigate breakage, we need something *like* Wine and Proton for stability and reliability's sake.

This can't be stressed enough. One of the biggest reasons gamedev is so much easier on Windows is because of Microsoft's commitment to backwards compatibility.... something a lot of Linux distros don't do well. Which usually means gamedevs have to package their external libs with the game (which many Linux diehards seem to dislike), use the Steam Runtime (which requires Steam).

Both options which are royal pains as I've had to do this myself for non-game related packaging where the libraries needed in the application I built were not available on some/most server distros because the system packages were far too old (in most cases actually End Of Life from the upstream maintainers of the programming language AND libraries) leading to either having to build for the least common denominator or building the entire thing into the package myself............ I'm forever scarred from that experience.

View this comment - View article - View full comments

Quoting: RuohtasThis is especially egregious for those of us that backed the KS specifically due to the native Linux client. They only met their funding goal by about $45K, and that could have been due to the Linux version availability.

And I can tell you now as I've spent a LOT of time on developing to improve margins. 45K isn't enough to fund a Linux version itself.

View this comment - View article - View full comments

Quoting: JosephThis company is a disappointment over another disappointment... With the pathetic launch, to the incomplete campaign, to a pathetic multiplayer launch (and even right now by today's standards)...

And today, I learn that this game, for which I backed up at the beginning for that very reason, is dropping the Linux support...

Anyway, the good news is, they can't really fall at a lower level.

I don't know man, I just feel scammed by a gaming company, yet again...

I mean, take your pick:

• AAA studios that are ready to screw you over (or rather the Investors are) for the sake of more profits, but they can also dedicate more resources to scaling online modes (which is expensive, and MORE expensive the MORE players are using it. I work on a cloud platform and the more successful we got, the more expensive the platform cost us. We literally have to cut features from customers because we were too successful and can't afford to keep running the platform).


• AA or Indie studios that become far more popular than their funds can afford to scale for and then have to cut features, versions of the game, or face performance issues... because they were too successful, but still don't have the money or personnel to scale.

View this comment - View article - View full comments

Quoting: GetBeanedI agree with everything you've said here. I know some people are very firm in supporting native versions so to pull the rug on it in this fashion sucks.

That said, in my experience, native versions are unfortunately almost always worse: missing features, worse performance, slower updates etc.

Honestly, I get really annoyed by the "Proton/WINE isn't native" arguments. If WINE or Proton were Emulation tools, I'd agree, but where emulation tries to mimic hardware and other aspects that simply can't be done "natively", WINE and Proton's other tools are actually rebuilding the Windows and DX APIs for use within Linux. As such, Proton/WINE are absolutely native but the very definition of what an API does. I'm speaking of this as a Software Dev myself that works with various APIs every day. I've said it before and I'll say it again, if WINE/Proton isn't "native", then no API is native.

View this comment - View article - View full comments