Support us on Patreon
PayPalWithout 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:
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
EagleDelta Sep 22
It'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
I'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?It'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?
It'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 Sep 22
TL;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
1 Likes, Who?
TL;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?
2 Likes, Who?
EagleDelta Sep 23
TL;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.
1 Likes, Who?
TL;DR: so it's much of an Ubuntu problem than anything else...
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.
Neovim is available in Arch-based repos at 0.10.1 version.
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.
I 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.
Last edited by Cyril on 24 September 2024 at 12:17 am UTC
0 Likes
They're a big studio, they should know way better.
They have maybe 30 to 40 employees, that's not a "big studio"
1 Likes, Who?
This 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.
And that's nice and all, but the point I was trying to make was that they may not have met that funding goal if they hadn't specifically called out a native Linux client.
2 Likes, Who?
EagleDelta Sep 30
Neovim 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.
I 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.
Last edited by EagleDelta on 30 September 2024 at 5:04 am UTC
2 Likes, Who?
Neovim 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.
But I'm not saying Arch-based are great for everybody, that was just an example where in this case the software with the right version is available in repos. From your last post I didn't know what repos specifically you were talking about (repos in general or repos in a particular distro). I read that as a complaint, if it wasn't then OK.
Finally, "Not a distro for you" is irrelevant when you are building software meant to run on all major distros.
It's not irrelevant as I was telling this solely for the neovim thing, nothing else. Neovim is not a dependency of a global software, it's a just a text editor that you need, it's not the same.
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.
I 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).
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.
As I said, different topic.
Last edited by Cyril on 1 October 2024 at 4:17 pm UTC
0 Likes
EagleDelta Oct 2
I 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.
Last edited by EagleDelta on 2 October 2024 at 2:08 am UTC
2 Likes, Who?
See more from me