DirectX 12 exclusive DEATH STRANDING runs on Linux with Proton 5.0-10

Quoting: Patola

Quoting: Redface

Quoting: Patola

Quoting: kaiman

Quoting: PatolaSpeaking of drivers, the 450.57 drivers got to the graphics-drivers PPA for Ubuntu 20.04

So much for Ubuntu LTS releases to get updated NVIDIA drivers without PPAs. :-(

Actually, 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.

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

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.

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.

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