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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: PatolaQuoting: kaimanActually, from my experience, the official Ubuntu repository gets updated a few days after the graphics-drivers PPA. The 440.100 driver came pretty quickly to the official repositories.Quoting: PatolaSpeaking of drivers, the 450.57 drivers got to the graphics-drivers PPA for Ubuntu 20.04So much for Ubuntu LTS releases to get updated NVIDIA drivers without PPAs. :-(
440.100 came pretty fast after Nvidia released them, but they also fixed some security bugs: https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-440/440.100-0ubuntu0.20.04.1
There should be 8 weeks of testing after release before a Stable Release Update (SRU) according to https://wiki.ubuntu.com/NVidiaUpdates
430, 435 and then 440 took a few weeks longer than 8 though, lets see how long it will be for 450.
450 is on groovy (the upcoming 20.10) already https://packages.ubuntu.com/groovy/nvidia-driver-450 but still missing i386 like the PPA did, but that will hopefully not take long. https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-450/+bug/1887814
1 Likes, Who?
Quoting: PatolaQuoting: RedfaceQuoting: PatolaQuoting: kaimanActually, from my experience, the official Ubuntu repository gets updated a few days after the graphics-drivers PPA. The 440.100 driver came pretty quickly to the official repositories.Quoting: PatolaSpeaking of drivers, the 450.57 drivers got to the graphics-drivers PPA for Ubuntu 20.04So much for Ubuntu LTS releases to get updated NVIDIA drivers without PPAs. :-(
440.100 came pretty fast after Nvidia released them, but they also fixed some security bugs: https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-440/440.100-0ubuntu0.20.04.1
There should be 8 weeks of testing after release before a Stable Release Update (SRU) according to https://wiki.ubuntu.com/NVidiaUpdates
430, 435 and then 440 took a few weeks longer than 8 though, lets see how long it will be for 450.
450 is on groovy (the upcoming 20.10) already https://packages.ubuntu.com/groovy/nvidia-driver-450 but still missing i386 like the PPA did, but that will hopefully not take long. https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-450/+bug/1887814
20.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.
Bugs 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.
Arch 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
Remember 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
0 Likes
On the part of the 32 bit packages of the 450 driver in the PPA. The bug was marked fixed 8 hours ago and I can indeed see the 32 packages now.
0 Likes
Quoting: PatolaQuoting: RedfaceYes, 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: 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.
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.04Which 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.
0 Likes
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
0 Likes
Patreon
PayPal
See more from me