Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

Not long after the official PC release, the DirectX 12 exclusive DEATH STRANDING is now playable on Linux with the Steam Play Proton compatibility layer.

Previously exclusive to the PlayStation 4, DEATH STRANDING is the latest game from Hideo Kojima and the first to come from Kojima Productions after the split from Konami back in 2015. The PC release also comes with a little Half-Life crossover and a special Photo Mode.

Valve staffer Pierre-Loup Griffais mentioned on Twitter, that they've put out a new Release Candidate (testing build) of the upcoming Proton 5.0-10 release. The linked issue report on the official Proton GitHub, created by Andrew Eikum from Valve partner CodeWeavers mentions that to run this build you need this setup:

The game does require the latest Nvidia and AMD drivers. We've had success on Nvidia with Nvidia drivers 440.100 and 450.57, and on AMD with Mesa 20.1.3 with LLVM 10.0.0. If you are on AMD and experience a graphics error dialog on startup, please restart the Steam client once to ensure you have the latest Proton configuration settings for the game.

Currently for Proton 5.0-10 the only mentioned change is getting DEATH STRANDING into a working state. Going by comments from people doing early testing, it's a little rough around the edges including: floating objects, crashes and so on—everything you expect from a testing build. Hopefully they will be able to get it into a proper released state soon. Getting a new DX12 title working so quickly under the Proton compatibility layer though is impressive with VKD3D-Proton.

To try it out, you need to opt into the Beta for Proton 5.0 within the Steam client. Here's a quick reminder on how to go about doing that:

If you do wish to buy DEATH STRANDING it can be picked up on Humble Store and Steam.

Article taken from GamingOnLinux.com.
33 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
34 comments
Page: «4/4
  Go to:

Patola 20 Jul
Quoting: Redface
Quoting: Patola20.10? I don't plan to use it. Hopefully I'll have migrated to Arch when it's out. I'm in a point that I can't stand Canonical idiosyncrasies anymore. This stupid bug repeating in 20.04 and 20.10 would not have even happened if not for their impopular idea of forcefully deprecating 32 bits. "Break things on purpose, expecting someone noticing it and reporting a bug"? Imagine the amount of games, applications and other software that will stop working just because someone did not notice, does not know how to open a bug report or does not care.

I cannot see any goodwill coming from Canonical lately. Deeply disappointed with them.

The bug never happened in 20.04, the PPA is not part of the distribution, it is unsupported. And the bug has been fixed in 20.10 already, which first will be released in 3 months.
Yes, for that reason I said explicitly that this PPA is maintained by Canonical people, though. And the process that filters out 32-bits (and needs them to be added to a whitelist) is due to Canonical's decision to stop supporting 32 bits. So, to me, it's still a Canonical bug. One that is not resolved at all, the filter still exists and need to not be applied in a case-by-case basis.

Quoting: RedfaceBugs can happen for any number of reasons, the PPAs and development versions do primarily exist so that bugs can be caught before an update to a released version.
Agreed - my focus was not on the lack of 32 bits on the repository itself but on the process in place to prevent 32 bits builds.

Quoting: RedfaceArch did deprecate 32bit support for installing on 32 bit only CPUs and only building packages needed to run 32 bits programs on a 64bit OS years before Ubuntu did that with 20.04. So if you do not like that they do not build 32 bit packages that no one will install on a 64 bit OS since they always will pick the 64bit version, then you should look else where, like Debian which still support full 32bit only installs, or an older Ubuntu LTS like 18.04
Which is very much a reasonable policy to me. I am against Canonical policy to prevent most 32-bits package, not against Arch policy to not build a full 32-bits distribution. The two are not comparable in my opinion, Arch still does daily builds of thousands of 32-bits packages.

Quoting: RedfaceRemember that Ubuntu 20.04 and and onward still support 32bit versions of all packages needed to run 32bit only programs as long the source package is in the distribution: https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility

This URL has the exact description of the problem I am criticizing: exclude 32-bits package unless someone is engaged enough to the distro to know this address, to engage on that discussion and comment on that post, or go through the other bureaucratic processes (e.g. launchpad) to package something for the distribution, and even then, it's not guaranteed to work. Imagine in, say, 4 years from now, someone will update Ubuntu and finds that an old obscure 32-bits package which is a dependency for these national government software, or game, or niche application does not work in Ubuntu anymore, AND it goes to the extremely improbable case of finding that URL, commenting there about what he needs. Do you actually think someone will even react to his comment? It will be easier for him to change to Debian, or Arch, or anything else that fits his needs. I am changing in advance, for that I have lots of 32-bits games (and a few apps) that I don't want to stop working out of the blue. And for the record, that is not the only reason, of course. I also don't want a distro riddled with unnecessarily containerized software that do not have shared libraries with the rest of the system, I also do not want to waste my time learning and using well crafted software that is suddenly abandoned (upstart, unity, mir), and so on and so forth. So, yes, I am sick of ubuntisms.

BTW: I think that Canonical is quickly losing their mindshare from indirect evidence. A little more than a year ago, we had repositories like the graphics-drivers-dev with NVIDIA beta drivers, or a few other PPAs with them. Nowadays we see each release of the NVIDIA beta drivers passing by and no Ubuntu packages by voluntaries anywhere, while for Arch and others they get it practically day one.


Last edited by Patola on 20 July 2020 at 9:53 pm UTC
Redface 23 Jul
Quoting: Patola
Quoting: Redface
Quoting: Patola20.10? I don't plan to use it. Hopefully I'll have migrated to Arch when it's out. I'm in a point that I can't stand Canonical idiosyncrasies anymore. This stupid bug repeating in 20.04 and 20.10 would not have even happened if not for their impopular idea of forcefully deprecating 32 bits. "Break things on purpose, expecting someone noticing it and reporting a bug"? Imagine the amount of games, applications and other software that will stop working just because someone did not notice, does not know how to open a bug report or does not care.

I cannot see any goodwill coming from Canonical lately. Deeply disappointed with them.

The bug never happened in 20.04, the PPA is not part of the distribution, it is unsupported. And the bug has been fixed in 20.10 already, which first will be released in 3 months.
Yes, for that reason I said explicitly that this PPA is maintained by Canonical people, though. And the process that filters out 32-bits (and needs them to be added to a whitelist) is due to Canonical's decision to stop supporting 32 bits. So, to me, it's still a Canonical bug. One that is not resolved at all, the filter still exists and need to not be applied in a case-by-case basis.

Quoting: RedfaceBugs can happen for any number of reasons, the PPAs and development versions do primarily exist so that bugs can be caught before an update to a released version.
Agreed - my focus was not on the lack of 32 bits on the repository itself but on the process in place to prevent 32 bits builds.

Quoting: RedfaceArch did deprecate 32bit support for installing on 32 bit only CPUs and only building packages needed to run 32 bits programs on a 64bit OS years before Ubuntu did that with 20.04. So if you do not like that they do not build 32 bit packages that no one will install on a 64 bit OS since they always will pick the 64bit version, then you should look else where, like Debian which still support full 32bit only installs, or an older Ubuntu LTS like 18.04
Which is very much a reasonable policy to me. I am against Canonical policy to prevent most 32-bits package, not against Arch policy to not build a full 32-bits distribution. The two are not comparable in my opinion, Arch still does daily builds of thousands of 32-bits packages.

Quoting: RedfaceRemember that Ubuntu 20.04 and and onward still support 32bit versions of all packages needed to run 32bit only programs as long the source package is in the distribution: https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility

This URL has the exact description of the problem I am criticizing: exclude 32-bits package unless someone is engaged enough to the distro to know this address, to engage on that discussion and comment on that post, or go through the other bureaucratic processes (e.g. launchpad) to package something for the distribution, and even then, it's not guaranteed to work. Imagine in, say, 4 years from now, someone will update Ubuntu and finds that an old obscure 32-bits package which is a dependency for these national government software, or game, or niche application does not work in Ubuntu anymore, AND it goes to the extremely improbable case of finding that URL, commenting there about what he needs. Do you actually think someone will even react to his comment? It will be easier for him to change to Debian, or Arch, or anything else that fits his needs. I am changing in advance, for that I have lots of 32-bits games (and a few apps) that I don't want to stop working out of the blue. And for the record, that is not the only reason, of course. I also don't want a distro riddled with unnecessarily containerized software that do not have shared libraries with the rest of the system, I also do not want to waste my time learning and using well crafted software that is suddenly abandoned (upstart, unity, mir), and so on and so forth. So, yes, I am sick of ubuntisms.

BTW: I think that Canonical is quickly losing their mindshare from indirect evidence. A little more than a year ago, we had repositories like the graphics-drivers-dev with NVIDIA beta drivers, or a few other PPAs with them. Nowadays we see each release of the NVIDIA beta drivers passing by and no Ubuntu packages by voluntaries anywhere, while for Arch and others they get it practically day one.

Ubuntu 32bit

No, you wrote "This stupid bug repeating in 20.04 and 20.10" while the bug was in the PPA and 20.10 and fixed both places. We talked about that it takes some time to get into 20.04.

You seem to think that the way Ubuntu implemented to support 32 bit programs on 64 bit systems going forward is a bug, or something else since you have some things misunderstood.

Having a white list is the best possible way forward to do that, and I have not looked how Arch selects 32 libraries to be build but it is probably also some form of whitelist.

Let me explain a bit about the packaging and build system.

Ubuntu and Arch both have the policy to build whats needed to run 32bit programs on 64bit systems.

They do have different package and build systems, so what works to achieve that for one might not work for the other.

Debian and Ubuntu and all their derivatives use multiarch where most other distributions including arch use mulitlib

See https://unix.stackexchange.com/questions/458069/multilib-and-multiarch#458077 for a short discussion about those and the differences.

Maintainers upload source packages to the build system.

All packages will normally be build for all architectures for multiarch. This is not the best way forward when only a subset is needed, so a blacklist would be very inefficient. That is why there is a whitelist.

What happened to the new Nvidia 450 drivers is that they technically are new packages, since multiple versions are needed, mainly for the legacy drivers, so the major version number is part of the package name. And the whitelist is based on package names. Most packages do not have the version number in their name so that would not have to be added again after an update, and for the nvidia drivers they could maybe add some wildcard, or else just have it n a checklist.




Arch does not build all packages for 32bit, they do build a set of

https://www.archlinux.org/packages/?sort=&q=lib32&maintainer=&flagged=

269 packages

and in the AUR https://aur.archlinux.org/packages/?O=0&SeB=nd&K=lib32&outdated=&SB=n&SO=a&PP=50&do_Search=Go

484 packages



20.04 has

apt list --all-versions|grep i386|wc -l

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

5470
packages

You can not compare number of packages directly since the distributions are to different, see https://en.wikipedia.org/wiki/Arch_Linux#Package_management for a short discussion of why. But the arch numbers show that a limited number of packages is needed, and Ubuntu 20.04 has a lot more, due to that the build dependencies also are needed as 32 bit packages.

And users do not have have to check for that list, it was made and added to before release of 20.04 with some additions since then.

If they really need another package in 32 bit where the source is in Ubuntu but not build for 32 then the easiest way is to just build from the source package, or else from upstream.
Just like for any other package any other distribution might not have, or not how the user wants them.
Patola 24 Jul
Quoting: Redface
Quoting: Patola
Quoting: Redface
Quoting: Patola20.10? I don't plan to use it. Hopefully I'll have migrated to Arch when it's out. I'm in a point that I can't stand Canonical idiosyncrasies anymore. This stupid bug repeating in 20.04 and 20.10 would not have even happened if not for their impopular idea of forcefully deprecating 32 bits. "Break things on purpose, expecting someone noticing it and reporting a bug"? Imagine the amount of games, applications and other software that will stop working just because someone did not notice, does not know how to open a bug report or does not care.

I cannot see any goodwill coming from Canonical lately. Deeply disappointed with them.

The bug never happened in 20.04, the PPA is not part of the distribution, it is unsupported. And the bug has been fixed in 20.10 already, which first will be released in 3 months.
Yes, for that reason I said explicitly that this PPA is maintained by Canonical people, though. And the process that filters out 32-bits (and needs them to be added to a whitelist) is due to Canonical's decision to stop supporting 32 bits. So, to me, it's still a Canonical bug. One that is not resolved at all, the filter still exists and need to not be applied in a case-by-case basis.

Quoting: RedfaceBugs can happen for any number of reasons, the PPAs and development versions do primarily exist so that bugs can be caught before an update to a released version.
Agreed - my focus was not on the lack of 32 bits on the repository itself but on the process in place to prevent 32 bits builds.

Quoting: RedfaceArch did deprecate 32bit support for installing on 32 bit only CPUs and only building packages needed to run 32 bits programs on a 64bit OS years before Ubuntu did that with 20.04. So if you do not like that they do not build 32 bit packages that no one will install on a 64 bit OS since they always will pick the 64bit version, then you should look else where, like Debian which still support full 32bit only installs, or an older Ubuntu LTS like 18.04
Which is very much a reasonable policy to me. I am against Canonical policy to prevent most 32-bits package, not against Arch policy to not build a full 32-bits distribution. The two are not comparable in my opinion, Arch still does daily builds of thousands of 32-bits packages.

Quoting: RedfaceRemember that Ubuntu 20.04 and and onward still support 32bit versions of all packages needed to run 32bit only programs as long the source package is in the distribution: https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility

This URL has the exact description of the problem I am criticizing: exclude 32-bits package unless someone is engaged enough to the distro to know this address, to engage on that discussion and comment on that post, or go through the other bureaucratic processes (e.g. launchpad) to package something for the distribution, and even then, it's not guaranteed to work. Imagine in, say, 4 years from now, someone will update Ubuntu and finds that an old obscure 32-bits package which is a dependency for these national government software, or game, or niche application does not work in Ubuntu anymore, AND it goes to the extremely improbable case of finding that URL, commenting there about what he needs. Do you actually think someone will even react to his comment? It will be easier for him to change to Debian, or Arch, or anything else that fits his needs. I am changing in advance, for that I have lots of 32-bits games (and a few apps) that I don't want to stop working out of the blue. And for the record, that is not the only reason, of course. I also don't want a distro riddled with unnecessarily containerized software that do not have shared libraries with the rest of the system, I also do not want to waste my time learning and using well crafted software that is suddenly abandoned (upstart, unity, mir), and so on and so forth. So, yes, I am sick of ubuntisms.

BTW: I think that Canonical is quickly losing their mindshare from indirect evidence. A little more than a year ago, we had repositories like the graphics-drivers-dev with NVIDIA beta drivers, or a few other PPAs with them. Nowadays we see each release of the NVIDIA beta drivers passing by and no Ubuntu packages by voluntaries anywhere, while for Arch and others they get it practically day one.

Ubuntu 32bit

No, you wrote "This stupid bug repeating in 20.04 and 20.10" while the bug was in the PPA and 20.10 and fixed both places. We talked about that it takes some time to get into 20.04.

You seem to think that the way Ubuntu implemented to support 32 bit programs on 64 bit systems going forward is a bug, or something else since you have some things misunderstood.

Having a white list is the best possible way forward to do that, and I have not looked how Arch selects 32 libraries to be build but it is probably also some form of whitelist.

Let me explain a bit about the packaging and build system.

Ubuntu and Arch both have the policy to build whats needed to run 32bit programs on 64bit systems.

They do have different package and build systems, so what works to achieve that for one might not work for the other.

Debian and Ubuntu and all their derivatives use multiarch where most other distributions including arch use mulitlib

See https://unix.stackexchange.com/questions/458069/multilib-and-multiarch#458077 for a short discussion about those and the differences.

Maintainers upload source packages to the build system.

All packages will normally be build for all architectures for multiarch. This is not the best way forward when only a subset is needed, so a blacklist would be very inefficient. That is why there is a whitelist.

What happened to the new Nvidia 450 drivers is that they technically are new packages, since multiple versions are needed, mainly for the legacy drivers, so the major version number is part of the package name. And the whitelist is based on package names. Most packages do not have the version number in their name so that would not have to be added again after an update, and for the nvidia drivers they could maybe add some wildcard, or else just have it n a checklist.




Arch does not build all packages for 32bit, they do build a set of

https://www.archlinux.org/packages/?sort=&q=lib32&maintainer=&flagged=

269 packages

and in the AUR https://aur.archlinux.org/packages/?O=0&SeB=nd&K=lib32&outdated=&SB=n&SO=a&PP=50&do_Search=Go

484 packages



20.04 has

apt list --all-versions|grep i386|wc -l

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

5470
packages

You can not compare number of packages directly since the distributions are to different, see https://en.wikipedia.org/wiki/Arch_Linux#Package_management for a short discussion of why. But the arch numbers show that a limited number of packages is needed, and Ubuntu 20.04 has a lot more, due to that the build dependencies also are needed as 32 bit packages.

And users do not have have to check for that list, it was made and added to before release of 20.04 with some additions since then.

If they really need another package in 32 bit where the source is in Ubuntu but not build for 32 then the easiest way is to just build from the source package, or else from upstream.
Just like for any other package any other distribution might not have, or not how the user wants them.
[10:48] [1767] [patola@risadinha patola]% apt list --all-versions|grep lib32 | wc -l

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

315
[10:49] [1768] [patola@risadinha patola]% 
Redface 24 Jul
Quoting: Patola[10:48] [1767] [patola@risadinha patola]% apt list --all-versions|grep lib32 | wc -l

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

315
[10:49] [1768] [patola@risadinha patola]% 

Ubuntu also supports multilib. If you grep for lib32 then you get mostly the libraries to crosscompile to 32bit for the various architectures, like for example


lib32stdc++6-10-dbg-sparc64-cross/focal,focal 10-20200411-0ubuntu1cross1 all
lib32stdc++6-10-dbg-x32-cross/focal,focal 10-20200411-0ubuntu1cross1 all


and some amd64 packages containing 32bit, those do not have cross in the name

The packages to support running 32bit are mostly in the i386 arch and do not have lib32 in the package name, so you have to search for i386 to find them. and append :i386 to install them and other operations. For example

apt show libsdl2-2.0-0:i386



to get info about the 32bit sdl2 library in Ubuntu
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.

Livestreams & Videos
Community Livestreams
Latest Forum Posts