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.
Quoting: EagleDeltaQuoting: 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.
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.
Quoting: EagleDeltaFinally, "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.
Quoting: EagleDeltaEspecially 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).
Quoting: EagleDeltaSo, 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
EagleDelta Oct 2
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.
Last edited by EagleDelta on 2 October 2024 at 2:08 am UTC
See more from me