Without any warning, Eleventh Hour Games have completely dropped support for and completely removed the Native Linux version of Last Epoch.
Initially, the patch notes didn't even mention Linux at all, but were later updated with the Steam Deck section expanded to include the notice. In the changelog they state "We’re no longer building a native Linux client and recommend Linux players use Proton on Linux which provides a much better experience".
For people who purchased specifically because it was advertised and sold on having a Native Linux version, it's not great and their communication after the fact is not a good look either. That said, Valve's Proton often really does offer a better experience. A lot of the time because of various game engine issues and/or just not a lot of time spent improving the Linux version. So Linux desktop and Steam Deck players can thankfully still play the game. From what I've seen, many players were already using Proton for it due to various problems.
The game currently has a Steam Deck Playable rating with Proton 9.
As for their promised Steam Deck improvements, they have now added UI scaling options with the latest update. However, a recent announcement noted they've pushed back some other changes as they "feel it’s important that when we say we are Steam Deck verified, players can trust that the experience they will receive on the Steam Deck is up to snuff with our expectations for player experience". So more to come there in future.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
EagleDelta about 16 hours ago
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.
0 Likes
Quoting: EagleDeltaI'm in a bit of a cleft stick here. On one hand, I firmly believe you know much more about this than I do. On the other hand, I've been using Linux distros for decades now, and they pretty definitely seem to have system libraries which an awful lot of the software seems to use. I fought with dependency hell far too much in the 00s to believe those software packages weren't dependent on system libraries. So it's like who am I going to believe, you or my lying eyes?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.
But in any case I can't help noticing that this issue, whether valid or not or partially, has nothing to do with the main point I was making. So I'll be assuming that as I suspected, there are not "many Linux diehards" complaining about bundling libraries in closed source games.
1 Likes, Who?
Quoting: EagleDeltaQuoting: 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.
TL;DR: so it's much of an Ubuntu problem than anything else...
0 Likes
EagleDelta about 3 hours ago
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.
Last edited by EagleDelta on 22 September 2024 at 6:29 pm UTC
0 Likes
Patreon
PayPal
See more from me