Are you ready for another Sony game on Steam? The UNCHARTED: Legacy of Thieves Collection arrives on October 19th, and it's been Steam Deck Verified already.
This is similar to what happened with Spider-Man Remastered, as clearly Valve and Sony are talking behind the scenes to get testing done and ensure the Windows ports are in good shape with the Proton compatibility layer. What a time to be alive, games from Sony releasing on Steam and being verified on a Linux gaming device. Still quite hard to believe but amazing to see.
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Direct Link
Direct Link
I do find it thoroughly odd that they're putting the newer games up before the originals, which is likely down to easier porting on these more modern games.
Will you be picking them up to play on Linux / Steam Deck? Let us know in the comments. I'll be taking a look with a video hopefully up soon after the release to see how it runs.
Available for pre-order on Humble Store and Steam.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityI wish Sony would release their more interesting games already. Uncharted can be fun but I’ve already played all four and have no reason I would want to return. Even if they bundled in a secret Uncharted 5. Truthfully the games are all too mechanically similar to warrant any replay.
And there it is. Instead of celebrating the fact this franchise is even coming to PC, and is playable day one on Linux, no less, we now have people in the Linux gaming community making entitled and selfish comments, like this.
Sure am!
Here’s a golf clap for Sony porting a game from Unix to Linux.
*patters hands*
Wooo hoo!
Unless I'm mistaken, they didn't port it to Linux; it's still a Windows game, running through Proton. But whatever.
IMO modern WINE makes Windows vs Linux gaming a case of semantics.
My snipe at Unix to Linux is to point out that the Playstations are traditionally Unix platforms. An OS that has traditionally not been used heavily for visual applications and is the cousin of Linux. So why did it take until almost 2022 to give us Linux gaming if we were playing on Unix the whole time?
I’m glad Sony is doing what they claimed would happen years ago when the PS3 was released. However this is not the game I’m looking for, life is waaaaaay too short to play through Uncharted multiple times.
Because Windows accounts for the majority of PC gaming, while Linux accounts for about 5% or so.
Linux is getting there, thanks to Steam Deck and Steam OS, but it's going to take some years.
I would rather developers continue to just use Proton. It makes life easier for developers, and doesn't have much of a big difference, performance wise. Plus it continues to get better all the time.
Hard disagree, go native.
Thing is; businesses are targeting immediate/relevant markets as they are all there to make money. So going native is just not possible at any rate as of now. Linux is not a targeted platform, Deck is a semi targeted platform but just because Valve offers compatibility tools and puts their weight behind it with device sales so Valve creates new Linux users ( which they wouldn"t touch it normally ) .
Plus; it has been proven multiple times that Linux can't guarentee a stable ABI, a stable platform.
Most recent example is; glibc change that happened upstream by glibc maintainers which are employed by Red Hat. They just broke EAC compatibility, couple of native games that has nothing to do with EAC, some tools like libstrangle with that change.
https://blog.hiler.eu/win32-the-only-stable-abi/ ( Details are in here )
Now from those affected apps standpoint; they didn't do anything wrong, they didn't deserve anything to see their apps just stopped working after a glibc update. You wouldn't see such a thing on Windows yet you see on Linux as various areas/projects are maintained by different companies and not all of them care about situation of other apps.
If affected app is open source; those kind of regressions is not really an issue as literally anyone can file a PR/MR in order to fix affected app and maintainer can just merge the fix.
If affected app is a prop game chances for getting a fix is slim to none. Because:
1-) Developer is not likely aware of regression.
2-) Even they are aware they would be scratching their heads about why their app that didn't see updates in a long time now just got broke.
3-) No interest in fixing that as per sales numbers their app has pretty much done all money from Windows platform, still works on that most important platform,they moved on to their next project/they have something better to do with their time.
So trying to pursue native releases is really just a pointless cause at this point. Better throw your app to Proton and see if it works oob, if it doesn't get in touch with Valve/Proton team to solve it, if you are extra friendly to that platform include a first class citizen Vulkan renderer with your game ( that is not possible for most developers as they didn't have a reason to target Vulkan in their multiplatform , multimillion AAA game never before so their expertise and engine side lacks it- Unreal and Unity Vulkan support sucks ass because Vulkan is not needed for anything but Android which with whole driver situation there it is also mostly a lost cause, GLES is in much better shape ) , test your app on Proton before releasing an update to see if it still works.
As most things/apps on native Linux side are open source ( apps, open source games ) making a breaking change like glibc people did really doesn't make a sound most of the time. As people just fix them and move on.
When prop apps are involved Linux doesn't provide a stable, bullet proof ABI as seen above, they might just broke for no reason because maintainer of the project that your app relies on just decided so.
Wine/Proton on the other hand is constantly moving and has much better chance to be immune for such issues.
PS: Arch Linux worked around that issue on their glibc. But not all distros will do it, Fedora most certainly won't do it.
0 Likes
Quoting: LeopardQuoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityI wish Sony would release their more interesting games already. Uncharted can be fun but I’ve already played all four and have no reason I would want to return. Even if they bundled in a secret Uncharted 5. Truthfully the games are all too mechanically similar to warrant any replay.
And there it is. Instead of celebrating the fact this franchise is even coming to PC, and is playable day one on Linux, no less, we now have people in the Linux gaming community making entitled and selfish comments, like this.
Sure am!
Here’s a golf clap for Sony porting a game from Unix to Linux.
*patters hands*
Wooo hoo!
Unless I'm mistaken, they didn't port it to Linux; it's still a Windows game, running through Proton. But whatever.
IMO modern WINE makes Windows vs Linux gaming a case of semantics.
My snipe at Unix to Linux is to point out that the Playstations are traditionally Unix platforms. An OS that has traditionally not been used heavily for visual applications and is the cousin of Linux. So why did it take until almost 2022 to give us Linux gaming if we were playing on Unix the whole time?
I’m glad Sony is doing what they claimed would happen years ago when the PS3 was released. However this is not the game I’m looking for, life is waaaaaay too short to play through Uncharted multiple times.
Because Windows accounts for the majority of PC gaming, while Linux accounts for about 5% or so.
Linux is getting there, thanks to Steam Deck and Steam OS, but it's going to take some years.
I would rather developers continue to just use Proton. It makes life easier for developers, and doesn't have much of a big difference, performance wise. Plus it continues to get better all the time.
Hard disagree, go native.
Thing is; businesses are targeting immediate/relevant markets as they are all there to make money. So going native is just not possible at any rate as of now. Linux is not a targeted platform, Deck is a semi targeted platform but just because Valve offers compatibility tools and puts their weight behind it with device sales so Valve creates new Linux users ( which they wouldn"t touch it normally ) .
Plus; it has been proven multiple times that Linux can't guarentee a stable ABI, a stable platform.
Most recent example is; glibc change that happened upstream by glibc maintainers which are employed by Red Hat. They just broke EAC compatibility, couple of native games that has nothing to do with EAC, some tools like libstrangle with that change.
https://blog.hiler.eu/win32-the-only-stable-abi/ ( Details are in here )
Now from those affected apps standpoint; they didn't do anything wrong, they didn't deserve anything to see their apps just stopped working after a glibc update. You wouldn't see such a thing on Windows yet you see on Linux as various areas/projects are maintained by different companies and not all of them care about situation of other apps.
If affected app is open source; those kind of regressions is not really an issue as literally anyone can file a PR/MR in order to fix affected app and maintainer can just merge the fix.
If affected app is a prop game chances for getting a fix is slim to none. Because:
1-) Developer is not likely aware of regression.
2-) Even they are aware they would be scratching their heads about why their app that didn't see updates in a long time now just got broke.
3-) No interest in fixing that as per sales numbers their app has pretty much done all money from Windows platform, still works on that most important platform,they moved on to their next project/they have something better to do with their time.
So trying to pursue native releases is really just a pointless cause at this point. Better throw your app to Proton and see if it works oob, if it doesn't get in touch with Valve/Proton team to solve it, if you are extra friendly to that platform include a first class citizen Vulkan renderer with your game ( that is not possible for most developers as they didn't have a reason to target Vulkan in their multiplatform , multimillion AAA game never before so their expertise and engine side lacks it- Unreal and Unity Vulkan support sucks ass because Vulkan is not needed for anything but Android which with whole driver situation there it is also mostly a lost cause, GLES is in much better shape ) , test your app on Proton before releasing an update to see if it still works.
As most things/apps on native Linux side are open source ( apps, open source games ) making a breaking change like glibc people did really doesn't make a sound most of the time. As people just fix them and move on.
When prop apps are involved Linux doesn't provide a stable, bullet proof ABI as seen above, they might just broke for no reason because maintainer of the project that your app relies on just decided so.
Wine/Proton on the other hand is constantly moving and has much better chance to be immune for such issues.
PS: Arch Linux worked around that issue on their glibc. But not all distros will do it, Fedora most certainly won't do it.
Nah, still should go native.
1 Likes, Who?
The case of a Stable ABI has been beaten to death in the kernel mailing list, and the stable ABI has been (to a certain degree, as you noticed) in user space by means of glibc and other infrastructural libraries. The ability to ship an application with all its required dependencies bundled, in such a manner like Flatpak and AppImage alleviate much of the "dependency hell", granted, they still rely on the relative stability of the main C library.
The case of SteamOS is special, in that it is catered by Valve, is an immutable system, and they can simply ignore to apply a given upstream update that can provoke such breakage, sure this means they have to test every single pertinent upstream update against their base and every piece in their platform that require it (and also users of Steam on Linux serve as a huge test bed in this regard). If Valve stays with a given version, it is even likely that some distributions will as well, or at least acknowledge the breaking change and either work around or decide to implement it and let their users deal with it.
I still think that targeting SteamOS as the main Linux compatibility should suffice for most apps/games, and it is actually why most high level proprietary applications (such as Maya, Davinci, and many others) settle on specific distributions and versions... It can be no different. Also embracing native support from any company will most likely avoid the breakage of stuff we saw with EAC and glibc, as their development teams, at least in theory, would be aware of such developments, and could correct/address things accordingly. Sure, assuming they know how the "Linux landscape" operates, and keep an eye on any of the big projects upcoming releases (glibc, openssl, xorg, wayland, nVidia, mesa, kernel, etc).
Sadly I do agree that win32 seems to be the most stable target (comfortable, as well), though less than ideal. Wine itself is known to break compatibility from one version to the next or even within patch versions, attempting to fix one app and breaking a bunch of others in the process. Fortunately things have gotten much better over the years, but even today with Proton, if you managed to get a given game working in one version of Proton (and have not played it for a while), it may break the next time you start it with a newer stable version of Proton, and what's worse (for those who do not know about this, is source of endless frustration), the prefix can be even left in such a state, that reverting to the working version of Proton causes the game/application to stop working altogether! (easy fix by removing the prefix, and allowing the newer or older version of Proton to recreate it, most often than not fixes the issue... Maybe a feature request for SteamOS and Deck at one point, an option within the GUI for simple purge of Proton prefixes, maybe even as part of games properties under the files section).
I am almost sure that as the Deck becomes more relevant in the course of the next year or two (even if an upgraded iteration appears), and more companies take interest on getting the most out of it, we'll see growing native adoption and further optimization, as also games become more complex and taxing on the underlying hardware. The point is still valid, though for those old games and apps that (such as 20+ year old games today that are difficult to get working), using the Windows version will most likely yield the best results, even if it won't work on modern versions of Windows.
The case of SteamOS is special, in that it is catered by Valve, is an immutable system, and they can simply ignore to apply a given upstream update that can provoke such breakage, sure this means they have to test every single pertinent upstream update against their base and every piece in their platform that require it (and also users of Steam on Linux serve as a huge test bed in this regard). If Valve stays with a given version, it is even likely that some distributions will as well, or at least acknowledge the breaking change and either work around or decide to implement it and let their users deal with it.
I still think that targeting SteamOS as the main Linux compatibility should suffice for most apps/games, and it is actually why most high level proprietary applications (such as Maya, Davinci, and many others) settle on specific distributions and versions... It can be no different. Also embracing native support from any company will most likely avoid the breakage of stuff we saw with EAC and glibc, as their development teams, at least in theory, would be aware of such developments, and could correct/address things accordingly. Sure, assuming they know how the "Linux landscape" operates, and keep an eye on any of the big projects upcoming releases (glibc, openssl, xorg, wayland, nVidia, mesa, kernel, etc).
Sadly I do agree that win32 seems to be the most stable target (comfortable, as well), though less than ideal. Wine itself is known to break compatibility from one version to the next or even within patch versions, attempting to fix one app and breaking a bunch of others in the process. Fortunately things have gotten much better over the years, but even today with Proton, if you managed to get a given game working in one version of Proton (and have not played it for a while), it may break the next time you start it with a newer stable version of Proton, and what's worse (for those who do not know about this, is source of endless frustration), the prefix can be even left in such a state, that reverting to the working version of Proton causes the game/application to stop working altogether! (easy fix by removing the prefix, and allowing the newer or older version of Proton to recreate it, most often than not fixes the issue... Maybe a feature request for SteamOS and Deck at one point, an option within the GUI for simple purge of Proton prefixes, maybe even as part of games properties under the files section).
I am almost sure that as the Deck becomes more relevant in the course of the next year or two (even if an upgraded iteration appears), and more companies take interest on getting the most out of it, we'll see growing native adoption and further optimization, as also games become more complex and taxing on the underlying hardware. The point is still valid, though for those old games and apps that (such as 20+ year old games today that are difficult to get working), using the Windows version will most likely yield the best results, even if it won't work on modern versions of Windows.
0 Likes
Quoting: LeopardThing is; businesses are targeting immediate/relevant markets as they are all there to make money. So going native is just not possible at any rate as of now.Yet there are thousands of native games on the market. Seems to blatantly contradict your assertion.
1 Likes, Who?
Quoting: tuubiQuoting: LeopardThing is; businesses are targeting immediate/relevant markets as they are all there to make money. So going native is just not possible at any rate as of now.Yet there are thousands of native games on the market. Seems to blatantly contradict your assertion.
No? It is mostly a non issue to get a native build for indies because engines they used has export options.
Article is about Uncharted which is an AAA game, message that started debate says/implies they should have gone with native.
So you really don't need to be pedantic here. You know very well what is being talked about here.
Last edited by Leopard on 17 October 2022 at 8:40 am UTC
0 Likes
Quoting: itscalledrealityQuoting: LeopardQuoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityI wish Sony would release their more interesting games already. Uncharted can be fun but I’ve already played all four and have no reason I would want to return. Even if they bundled in a secret Uncharted 5. Truthfully the games are all too mechanically similar to warrant any replay.
And there it is. Instead of celebrating the fact this franchise is even coming to PC, and is playable day one on Linux, no less, we now have people in the Linux gaming community making entitled and selfish comments, like this.
Sure am!
Here’s a golf clap for Sony porting a game from Unix to Linux.
*patters hands*
Wooo hoo!
Unless I'm mistaken, they didn't port it to Linux; it's still a Windows game, running through Proton. But whatever.
IMO modern WINE makes Windows vs Linux gaming a case of semantics.
My snipe at Unix to Linux is to point out that the Playstations are traditionally Unix platforms. An OS that has traditionally not been used heavily for visual applications and is the cousin of Linux. So why did it take until almost 2022 to give us Linux gaming if we were playing on Unix the whole time?
I’m glad Sony is doing what they claimed would happen years ago when the PS3 was released. However this is not the game I’m looking for, life is waaaaaay too short to play through Uncharted multiple times.
Because Windows accounts for the majority of PC gaming, while Linux accounts for about 5% or so.
Linux is getting there, thanks to Steam Deck and Steam OS, but it's going to take some years.
I would rather developers continue to just use Proton. It makes life easier for developers, and doesn't have much of a big difference, performance wise. Plus it continues to get better all the time.
Hard disagree, go native.
Thing is; businesses are targeting immediate/relevant markets as they are all there to make money. So going native is just not possible at any rate as of now. Linux is not a targeted platform, Deck is a semi targeted platform but just because Valve offers compatibility tools and puts their weight behind it with device sales so Valve creates new Linux users ( which they wouldn"t touch it normally ) .
Plus; it has been proven multiple times that Linux can't guarentee a stable ABI, a stable platform.
Most recent example is; glibc change that happened upstream by glibc maintainers which are employed by Red Hat. They just broke EAC compatibility, couple of native games that has nothing to do with EAC, some tools like libstrangle with that change.
https://blog.hiler.eu/win32-the-only-stable-abi/ ( Details are in here )
Now from those affected apps standpoint; they didn't do anything wrong, they didn't deserve anything to see their apps just stopped working after a glibc update. You wouldn't see such a thing on Windows yet you see on Linux as various areas/projects are maintained by different companies and not all of them care about situation of other apps.
If affected app is open source; those kind of regressions is not really an issue as literally anyone can file a PR/MR in order to fix affected app and maintainer can just merge the fix.
If affected app is a prop game chances for getting a fix is slim to none. Because:
1-) Developer is not likely aware of regression.
2-) Even they are aware they would be scratching their heads about why their app that didn't see updates in a long time now just got broke.
3-) No interest in fixing that as per sales numbers their app has pretty much done all money from Windows platform, still works on that most important platform,they moved on to their next project/they have something better to do with their time.
So trying to pursue native releases is really just a pointless cause at this point. Better throw your app to Proton and see if it works oob, if it doesn't get in touch with Valve/Proton team to solve it, if you are extra friendly to that platform include a first class citizen Vulkan renderer with your game ( that is not possible for most developers as they didn't have a reason to target Vulkan in their multiplatform , multimillion AAA game never before so their expertise and engine side lacks it- Unreal and Unity Vulkan support sucks ass because Vulkan is not needed for anything but Android which with whole driver situation there it is also mostly a lost cause, GLES is in much better shape ) , test your app on Proton before releasing an update to see if it still works.
As most things/apps on native Linux side are open source ( apps, open source games ) making a breaking change like glibc people did really doesn't make a sound most of the time. As people just fix them and move on.
When prop apps are involved Linux doesn't provide a stable, bullet proof ABI as seen above, they might just broke for no reason because maintainer of the project that your app relies on just decided so.
Wine/Proton on the other hand is constantly moving and has much better chance to be immune for such issues.
PS: Arch Linux worked around that issue on their glibc. But not all distros will do it, Fedora most certainly won't do it.
Nah, still should go native.
Shit, what a troll. :D
0 Likes
Quoting: LeopardQuoting: tuubiQuoting: LeopardThing is; businesses are targeting immediate/relevant markets as they are all there to make money. So going native is just not possible at any rate as of now.Yet there are thousands of native games on the market. Seems to blatantly contradict your assertion.
No? It is mostly a non issue to get a native build for indies because engines they used has export options.
Article is about Uncharted which is an AAA game, message that started debate says/implies they should have gone with native.
So you really don't need to be pedantic here. You know very well what is being talked about here.
I do know what is being talked about, and I also know I've got native AAA games that still work fine several years after release. I quoted and replied to a specific assertion of yours. "Going native" is clearly not impossible, or even prohibitively hard from a technical standpoint. I am not being pedantic. I am simply refusing to accept your hyperbole.
Developing for and publishing on Linux might not be judged desirable for short-sighted business reasons, but that's just shifting the goal posts. Business decisions are not always logical, and they're often made by people whose only concern is to produce nice graphs pointing upwards for the next quarterly report, additionally influenced by the sort of largely unfounded prejudice you're putting forward here. We've heard this sort of FUD about Linux for a couple of decades now, and it's less true now than it was back then.
An indie dev might just be pushing a button in an export dialog (and hopefully doing a bit of QA before release), but someone developed that game engine and managed to make it support Linux in the first place. AAA devs are very likely to possess the resources to do that with their own games and engines, but of course that doesn't mean they're obligated to do so.
EAC broke due to an unfortunate combination of poor technical decisions on their part (apparently relying on an ELF section that had been de-facto deprecated for more than a decade), and arguably poor handling of the whole deprecation and removal process by the glibc maintainers, but it's not as if you can't find instances of games and software getting broken by Windows updates just as—if not even more—easily. I fully understand that there are reasons why supporting Linux requires effort that many developers are unwilling to put in, and expertise they might be lacking. Who am I to say that their reasons are all invalid. In the end it's their decision, and I'm not too bothered either way.
In any case, I suspect investors and publishers will forget all about the supposed technical barriers if the Linux gaming market ever grows large enough to make it harder to ignore.
2 Likes, Who?
Quoting: LeopardQuoting: itscalledrealityQuoting: LeopardQuoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityQuoting: MrowlQuoting: itscalledrealityI wish Sony would release their more interesting games already. Uncharted can be fun but I’ve already played all four and have no reason I would want to return. Even if they bundled in a secret Uncharted 5. Truthfully the games are all too mechanically similar to warrant any replay.
And there it is. Instead of celebrating the fact this franchise is even coming to PC, and is playable day one on Linux, no less, we now have people in the Linux gaming community making entitled and selfish comments, like this.
Sure am!
Here’s a golf clap for Sony porting a game from Unix to Linux.
*patters hands*
Wooo hoo!
Unless I'm mistaken, they didn't port it to Linux; it's still a Windows game, running through Proton. But whatever.
IMO modern WINE makes Windows vs Linux gaming a case of semantics.
My snipe at Unix to Linux is to point out that the Playstations are traditionally Unix platforms. An OS that has traditionally not been used heavily for visual applications and is the cousin of Linux. So why did it take until almost 2022 to give us Linux gaming if we were playing on Unix the whole time?
I’m glad Sony is doing what they claimed would happen years ago when the PS3 was released. However this is not the game I’m looking for, life is waaaaaay too short to play through Uncharted multiple times.
Because Windows accounts for the majority of PC gaming, while Linux accounts for about 5% or so.
Linux is getting there, thanks to Steam Deck and Steam OS, but it's going to take some years.
I would rather developers continue to just use Proton. It makes life easier for developers, and doesn't have much of a big difference, performance wise. Plus it continues to get better all the time.
Hard disagree, go native.
Thing is; businesses are targeting immediate/relevant markets as they are all there to make money. So going native is just not possible at any rate as of now. Linux is not a targeted platform, Deck is a semi targeted platform but just because Valve offers compatibility tools and puts their weight behind it with device sales so Valve creates new Linux users ( which they wouldn"t touch it normally ) .
Plus; it has been proven multiple times that Linux can't guarentee a stable ABI, a stable platform.
Most recent example is; glibc change that happened upstream by glibc maintainers which are employed by Red Hat. They just broke EAC compatibility, couple of native games that has nothing to do with EAC, some tools like libstrangle with that change.
https://blog.hiler.eu/win32-the-only-stable-abi/ ( Details are in here )
Now from those affected apps standpoint; they didn't do anything wrong, they didn't deserve anything to see their apps just stopped working after a glibc update. You wouldn't see such a thing on Windows yet you see on Linux as various areas/projects are maintained by different companies and not all of them care about situation of other apps.
If affected app is open source; those kind of regressions is not really an issue as literally anyone can file a PR/MR in order to fix affected app and maintainer can just merge the fix.
If affected app is a prop game chances for getting a fix is slim to none. Because:
1-) Developer is not likely aware of regression.
2-) Even they are aware they would be scratching their heads about why their app that didn't see updates in a long time now just got broke.
3-) No interest in fixing that as per sales numbers their app has pretty much done all money from Windows platform, still works on that most important platform,they moved on to their next project/they have something better to do with their time.
So trying to pursue native releases is really just a pointless cause at this point. Better throw your app to Proton and see if it works oob, if it doesn't get in touch with Valve/Proton team to solve it, if you are extra friendly to that platform include a first class citizen Vulkan renderer with your game ( that is not possible for most developers as they didn't have a reason to target Vulkan in their multiplatform , multimillion AAA game never before so their expertise and engine side lacks it- Unreal and Unity Vulkan support sucks ass because Vulkan is not needed for anything but Android which with whole driver situation there it is also mostly a lost cause, GLES is in much better shape ) , test your app on Proton before releasing an update to see if it still works.
As most things/apps on native Linux side are open source ( apps, open source games ) making a breaking change like glibc people did really doesn't make a sound most of the time. As people just fix them and move on.
When prop apps are involved Linux doesn't provide a stable, bullet proof ABI as seen above, they might just broke for no reason because maintainer of the project that your app relies on just decided so.
Wine/Proton on the other hand is constantly moving and has much better chance to be immune for such issues.
PS: Arch Linux worked around that issue on their glibc. But not all distros will do it, Fedora most certainly won't do it.
Nah, still should go native.
Shit, what a troll. :D
I think you should always try to go native. There will always be lots of reasons to not go-native and ways to run software on Linux. You shouldn’t be deterred because something is “hard”.
0 Likes
Quoting: LeopardPS: Arch Linux worked around that issue on their glibc. But not all distros will do it, Fedora most certainly won't do it.
Even Fedora took the sensible decision to not break things for fc37 https://bugzilla.redhat.com/show_bug.cgi?id=2129358
(As far as I’m aware, fc36 is not affected)
0 Likes
Quoting: jensQuoting: LeopardPS: Arch Linux worked around that issue on their glibc. But not all distros will do it, Fedora most certainly won't do it.
Even Fedora took the sensible decision to not break things for fc37 https://bugzilla.redhat.com/show_bug.cgi?id=2129358
(As far as I’m aware, fc36 is not affected)
Nice, hopefully others do it as well.
0 Likes
Patreon
PayPal
See more from me