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.
EagleDelta about 3 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.
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.
Patreon
PayPal
See more from me