Valve Reaffirms Commitment To Linux While Also Releasing Updated Proton

[the_scx]

How did you get a headache for Ubuntu not keeping 32 bit packages up to date with a yet-to-be-released version?

Valve wants 32 bit support => Valve keeps the packages up-to-date and throw them into ~/.steam, much like they do with anything else. They deploy the 32 bit Windows binaries, they deploy Proton with a ton of binaries thrown together, but throwing a bunch of more Linux libs is suddenly a showstopper? Are you really that ignorant?

They're plain lazy, that's all. Canonical, pls do the work for us some more! Valve relied on 3rd party stuff (in this case, the 3rd party is Canonical), but that doesn't make it something Canonical wants and needs. If Valve wants to run cross-architecture cross-platform stuff, it's 100% their liability.

No distro on Earth will keep 32-bit support forever. Valve can pretend it's the distro's task to provide them with something pretty much only they need, they can hop distros every 2 years, but that's not getting us anywhere. After all the struggles of SteamOS, it's pretty clear that they're not only lazy, but incompetent too.

Not that it wasn't obvious right from the start. Linux gaming has always been a pipe dream and not much else.

You are the only one who is lazy and incompetent here. You are completely clueless here. You have no idea what you are talking about. Valve already provides Steam Runtime which make the Steam client and games almost independent of any distro. However, it still depends on some basic components, like glibc or GPU drivers, because there is no sane way to do this otherwise. We don't want to back to DOS times, in which every single game developer had to deliver GPU drivers, because it is an extremely stupid approach.

https://www.phoronix.com/forums/forum/phoronix/general-discussion/1107050-ubuntu-19-10-to-drop-32-bit-x86-packages?p=1107452#post1107452

Because it would be the same mess that is already in Flatpak. They will have to support every single GPU driver. By that I mean every single version of the GPU driver, e.g. NVIDIA 304.134 (32-bit), NVIDIA 304.134 (64-bit), NVIDIA 304.135 (32-bit), NVIDIA 304.135 (64-bit), NVIDIA 340.101 (32-bit), NVIDIA 340.101 (64-bit), NVIDIA 340.102 (32-bit), NVIDIA 340.102 (64-bit), NVIDIA 340.104 (32-bit), NVIDIA 340.104 (64-bit), NVIDIA 340.106 (32-bit), NVIDIA 340.106 (64-bit), NVIDIA 367.57 (32-bit), NVIDIA 367.57 (64-bit), NVIDIA 370.28 (32-bit), NVIDIA 370.28 (64-bit), NVIDIA 375.26 (32-bit), NVIDIA 375.26 (64-bit), NVIDIA 375.39 (32-bit), NVIDIA 375.39 (64-bit), NVIDIA 375.66 (32-bit), NVIDIA 375.66 (64-bit), NVIDIA 375.82 (32-bit), NVIDIA 375.82 (64-bit), NVIDIA 378.13 (32-bit), NVIDIA 378.13 (64-bit), NVIDIA 381.09 (32-bit), NVIDIA 381.09 (64-bit), NVIDIA 381.22 (32-bit), NVIDIA 381.22 (64-bit), NVIDIA 384.47 (32-bit), NVIDIA 384.47 (64-bit), NVIDIA 384.59 (32-bit), NVIDIA 384.59 (64-bit), NVIDIA 384.69 (32-bit), NVIDIA 384.69 (64-bit), NVIDIA 384.90 (32-bit), NVIDIA 384.90 (64-bit), NVIDIA 384.98 (32-bit), NVIDIA 384.98 (64-bit), NVIDIA 384.111 (32-bit), NVIDIA 384.111 (64-bit), NVIDIA 384.130 (32-bit), NVIDIA 384.130 (64-bit), NVIDIA 387.12 (32-bit), NVIDIA 387.12 (64-bit), NVIDIA 387.22 (32-bit), NVIDIA 387.22 (64-bit), NVIDIA 387.34 (32-bit), NVIDIA 387.34 (64-bit), NVIDIA 390.12 (32-bit), NVIDIA 390.12 (64-bit), NVIDIA 390.25 (32-bit), NVIDIA 390.25 (64-bit), NVIDIA 390.42 (32-bit), NVIDIA 390.42 (64-bit), NVIDIA 390.48 (32-bit), NVIDIA 390.48 (64-bit), NVIDIA 390.59 (32-bit), NVIDIA 390.59 (64-bit), NVIDIA 396.24 (32-bit), NVIDIA 396.24 (64-bit), ..., NVIDIA 430.26 (32-bit), NVIDIA 430.26 (64-bit). The userspace driver version have to match the kernel driver version. Multiply it by every GPU vendor, including less known ones, such as VIA/S3G/Zhaoxin.

You have to be a complete ignorant to criticize Valve here. This corporation has done more for gaming on Linux than any other company.

[moilami]

Canonicals partial reversal doesn't make much sense but makes more sense than their original plans. It does not make any sense because it would take more man hours to try to figure out what packages are a dependancy for a binary-only 32 bit application for which a 64 bit binary is not available or which cannot be compiled to 64 bits, than to simply continue building all 32 bit software . Some packages will be accidentally ommited from the 32 bit build, leading to breakages. Breakages which are unnecessary.

It takes no extra man hours for canonical to build all 32 bit packages. But a lot of extra man hours for any kind of attempt to remove some 32 bit packages.

Canonicals behaviour seems fishy. The whole thing seemed to be a big punch in the face to Canonicals desktop users and to gamers. Is Canonical in bed with Microsoft and doing things that will damage Ubuntu on the desktop to push people towards Microsoft products? Could they be in bed with Sony Playstation or Nintendo and are working on their behalf to get rid of Ubuntus gamers and desktop users?. It really makes me wonder because Canonical has shown it could care less about its desktop users and actually does things to hurt them.

I think they are just idiots. Of course someone could had manipulated them, but it does not change the fact that they are idiots. This is very strong language from me, I hardly ever go personal, but this situation demands it in order to describe the situation the best.

[doctorx69]

It a shared source tree between Windows, OS X and Linux. Valve have released 64 bit clients for OS X. Really take your 32 bit client and be grateful is backwards. Valve should be grateful Ubuntu has not done worse than threaten to drop 32bit support.

Canonical(ubuntu) and Redhat could get along quite well without Valve as well. Zero income to Canonical or Redhat comes from the gamer market.



Did you pay for support on any of those desktops. I would guess no. 80 percent of the Linux userspace are not using 32 libraries. In that 80 percent are the ones paying Redhat and Canonical.

RHEL7 in 2014 from Redhat does not have 32 bit support you cannot install steam on that or use 32 bit wine or use 32 bit printer drivers. The last version of redhat that you can install steam on is RHEL6 that was release in 2010 they have dropped the 32 bit kernel from Fedora already as they will not be needing another kernel 32 kernel for long term support for RHEL6. Redhat will not be needing to be testing client side 32 bit libraries past the end of 2020 for the products they sell.

I am sorry to say slalomsk8er both you and Valve have basically been freeloading off the enterprise distributions.

I serous-ally do mean freeloading. Canonical and Redhat are making zero income from x86 32 bit library support. x86 32 bit support is a drain on both Canonical and Redhat bottom line.

SUSE may still have 32 bit support but they have removed the ability to build and they do not promise that installing 32 bit library will not bring you system crashing into complete non functional death in fact there manual goes on to warn you that using 32 bit runtime may result in your install no longer working.

Welcome to o great. None of the major enterprise distributions have any interest in keeping 32 bit x86 going.

Valve, Codeweavers and other parties who in fact have business models where they make money off 32 bit support working really need form a collective and form their own kind of distribution that takes care of x86 32 bit on Linux. You cannot expect to freeload forever without having to put up with the one making the money altering the rules the way they like.

2020 the year OS X and Redhat decide they no longer need 32 bit x86. 2019 Canonical wakes up in 2020 they are going to be left holding the 32 bit x86 maintenance bill and they really don't have the volume of staff to handle it without Suse or Redhat support. Yes Canonical will be attempting to cut 32 bit library support to the bone and most likely this will still break some of valve games and Canonical going to be like suffer you are not paying us Valve and you bad mouthed us Valve.

Valve has serous-ally responded to this problem completely the wrong way.

You dont know wtf you are talking about. RHEL7 DOES support 32bit libraries you moron.

From RH: https://access.redhat.com/solutions/509373

However, 32-bit applications are supported in a 64-bit RHEL 7 environment in the following scenarios:

• RHEL 7 will continue to provide selected libraries in both 32-bit and 64-bit, allowing 32-bit applications to run in the 64-bit RHEL 7 OS environment. This functionality also exists for RHEL 5 & 6 as documented in the knowledge article: How to install 32-bit packages on a 64-bit system
• RHEL 7 will continue to support the multilib toolchain, allowing applications to be compiled for both 32-bit and 64-bit.
• RHEL 7 can host, using KVM virtualization technology, both 32-bit and 64-bit virtual guest instances of RHEL 5 and RHEL 6.

Stop fucking saying that since we didnt pay for the os so stfu! Well, I hate to break it to you but the Linux world would not even be here if it wasnt free. Your fucking enterprise bullshit statement go to show you have no idea how the process works. Fedora is RH free playground. Once they have something stable (from mostly unpaid contributors), then it gets promoted up to rhel. Canonical has Ubuntu Server. It is free, but you can pay for support. Ubuntu desktop is their playground. If it wasnt for the Desktop, neither would exist. At one time, Red Hat was just a desktop OS. You cannot freeload off of something that is already free.

I also need to state, 32 bit is not even enabled in Ubuntu natively. You have to enable it with dpkg. Eliminating 32bit wont make your system magically faster, more stable or anything else.

[doctorx69]

Not true. It does hamper you system. In enterprise server usage memory usage, cpu usage and disc usage is important when you are deploying on the cloud. i686 32 bit software in fact uses more disc space than its x86-64 equal. i686 32bit software consumes more cpu performing the same task as x86-64 equal so has a larger effect on the performance of your system. Horrible in most cases i686 32 bit uses more ram than x86-64 equal.

Please note that was pure i686 userspace vs pure x86-64 userspace issues. The memory issue get worse when you wake up having 32 bit software and 64 bit software loaded at the same time you have duplicated up on items like glibc in memory. Disc usage basically over doubles in places. Due more items to manage in memory even your cpu usage gets worse.

Enterprise market has no interest in Multilib to support i686 32 bit software because of the harm it brings in their market. Desktop users the harm of Multilib can be ignored but those parties are not paying to the maintenance of software.

The idea that multilib does not hamper your system is wrong. Multilib was a trade off that was thought be good idea because 32 bit pointers are smaller than 64 bit pointers so i686 programs should be more effective right? Problem is this turns out due to the improvements in the x86-64/AMD64 instruction set this is not the case. So multilib is basically a boat ancher on performance.


openSUSE does not promise you that installing multilib will not leave your system unbootable. They removed direct building of 32 bit programs a long time ago.

There is fairly much no where with enterprise support to run to get 32 bit x86 support.

Again.. you dont know wtf you are talking about. We are not talking about a damned server here.

However, 32-bit applications are supported in a 64-bit RHEL 7 environment in the following scenarios:

• RHEL 7 will continue to provide selected libraries in both 32-bit and 64-bit, allowing 32-bit applications to run in the 64-bit RHEL 7 OS environment. This functionality also exists for RHEL 5 & 6 as documented in the knowledge article: How to install 32-bit packages on a 64-bit system
• RHEL 7 will continue to support the multilib toolchain, allowing applications to be compiled for both 32-bit and 64-bit.
• RHEL 7 can host, using KVM virtualization technology, both 32-bit and 64-bit virtual guest instances of RHEL 5 and RHEL 6.

[doctorx69]

You forget, that Canonical not have to compile only a few 32 bits libraries/programs. There are thousands of them. Many of them are practical not used anymore.

One reason to drop 32 bits is that compiling a library or a program requires time. Some of them, more than a day. So removing many of the 32 bit packages would save this time.

I am pretty sure, that are more cases, where dropping 32 bits library would save time and money.

I believe this is an automated process? There are daily builds for a reason?

[doctorx69]

Too everyone says Valve is freeloading... They are a multi billion dollar company that has thrown substantial support to Linux. Gaming is a $200+ billion industry. No one in their right mind would ignore that environment. Windows used to be ridiculed for trying to take gaming from DOS. It wasn't until win98 that MS started to get something right. Linux is now in the winxp stage of gaming. Really starting to fly.. and you purists (rebels without a cause) want to kneecap that possible customer base. Windows is becoming irrelevant for most things desktops are used for. In fact my damned outlook on my work laptop is just a shell interface to outlook 365 on the web. MS knows this. HEre is an anecdote: MS was going to deprecate win32 apps and only allow winrt. They even tried ham fisted approach and it fail....badly! The result? win32 will now be allowed in their store. This is what pisses me off about these fucking elitist saying 32bit software should die. Are you MS? No? then stop acting like it. You are making linux look bad. One argument was security issues including Intel CPU security vulns. Well good thing i run AMD. In fact, lets disable all Intel cpu support because of security issues. That is exactly the absurd argument being made here.

[doctorx69]

How did you get a headache for Ubuntu not keeping 32 bit packages up to date with a yet-to-be-released version?

Valve wants 32 bit support => Valve keeps the packages up-to-date and throw them into ~/.steam, much like they do with anything else. They deploy the 32 bit Windows binaries, they deploy Proton with a ton of binaries thrown together, but throwing a bunch of more Linux libs is suddenly a showstopper? Are you really that ignorant?

They're plain lazy, that's all. Canonical, pls do the work for us some more! Valve relied on 3rd party stuff (in this case, the 3rd party is Canonical), but that doesn't make it something Canonical wants and needs. If Valve wants to run cross-architecture cross-platform stuff, it's 100% their liability.

No distro on Earth will keep 32-bit support forever. Valve can pretend it's the distro's task to provide them with something pretty much only they need, they can hop distros every 2 years, but that's not getting us anywhere. After all the struggles of SteamOS, it's pretty clear that they're not only lazy, but incompetent too.

Not that it wasn't obvious right from the start. Linux gaming has always been a pipe dream and not much else.

With your attitude... it will never succeed.

[Ipkh]

Who's talking about i386 libraries? Noone targets that anymore. We are talking about 32bit, generally aimed at i686 Pentium, something with a fpu.

Is Canonical freeloading off of Debian? Even off of the free publicity and adoption by being recommended by Steam?

There is no freeloading involved. You can't freeloading off of Ubuntu or Linux in general due to its GPL license. And Canonical certainly gains from the community.

[GreenReaper]

People are saying i386 because it is the most usual term. It's what Debian uses for popcon even though it now requires a i686 (Pentium Pro/P2) at a minimum. The calling conventions do not differ so these can be used with software compiled for earlier processors.

The talk above about popcon reporting multiple arches does not appear to be correct. It seems to just report the native architecture from dpkg and collapses any multarch libs. I ran popcon before and after adding i386 architecture and the i386 libc++6 and the result had the same number of lines. So the number listed on popcon is i386 and AMD64 native installs, not "how many can run 32-bit" (or, for that matter, 64-bit).
https://lists.debian.org/debian-popc.../msg00008.html
(subsequent messages suggest detecting mixed installs should be something it does, but in practice it seems it was just made to report it if it was installed for any arch, or maybe just with the native arch).

Not that installing is exceedingly complex, as an installer script could simply call dpkg to add the architecture, apt update, and apt install steam.

As for Ubuntu they were planning this back in 2016, and Steam was mentioned at the start (quoted text):
https://lists.ubuntu.com/archives/ub...ne/039420.html

Understandably though the conversation turned more towards the needs of machines that could not install 64-bit, or did not over memory issues.

The cost of a build infrastructure is relatively small. Debian runs it on four servers, donated by HPE and hosted by universities. And they are the same servers which do 64-bit as well.
https://buildd.debian.org/status/arc...&suite=stretch

Potentially mirror space is more significant but the real cost is developer attention and support. Perhaps we will see a supported package framework where people or more likely companies pay for time spent, as with Debian's Extended LTS program by Freexian.

https://deb.freexian.com/extended-lts/

https://deb.freexian.com/extended-lt...rted-packages/

[oiaohm]

Steam should definitely remain 32-bit because (1) it's smaller (who cares of perf here)

This is in fact false. You can go look at the debian package archive.

https://packages.debian.org/buster/kwrite

Normal is x86_64 to be smaller than its i386/i686 version.

and (2) forces distros to keep multi-lib for people who play 32-bit games. Just because you don't, doesn't mean others don't. I buy a 32-bit game and I expect it to be playable forever. Period.

Really you said playable forever. Remember distributions in multilib only provide 1 version of libraries. So when there are ABI breakage in those libraries game does not work any more and steam runtime has to be used anyhow.

Distributions keeping multilib don't make your programs playable forever.