Valve Reaffirms Commitment To Linux While Also Releasing Updated Proton

[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]

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]

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.

[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.

[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.

[jpg44]

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.

[the_scx]

At this point I have to say that you're either a troll, or a cargo cultist type of user, you clearly have no idea what are you talking about.

He is just a troll. In another topic, he suggested that QEMU and Virgil should be good enough for gaming. He also believes that Huawei is able to design a new RISC-V SoC for hi-end smartphones in just two months! What's more, he said that they could use the open hardware Vulkan accelerator (expected specification in 2020: no OpenGL/OpenCL support, 720p@25FPS, 100 Mpixels/sec, 30 Mtriangles/sec, 5-6 GFLOPs, 2.5 W at 28 nm) in this.

[Nocifer]

Starving journalists that are desperate for click bait titles

Have a look at the timeline:

1. Announcement @Tue Jun 18 15:36:45 UTC 2019
2. Drama over the weekend
3. clarifying statement on Monday @2019-06-24-17-41-20 I guess UTC

Did I miss something?

Yup. You missed the fact that Canonical's timing and PR handling was so amateurish that even Valve, in the week between the first statement on Tuesday and the second "clarifying statement" on Monday, resorted to publicly announcing the end of support for Ubuntu as far as Steam is concerned. If even Valve was caught with its pants down by Canonical, imagine how the rest of us felt.

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.

So you're actually saying that enterprise servers around the world are being hampered in their performance due to them having the 32-bit Steam client installed..? Am I understanding you correctly?

I wonder if a company like Valve is large enough to demand source code for the games.

Nope. First of all, Valve are a game developer themselves, so they count as "competition" to most game dev companies out there. And second, I'd imagine that game dev companies (like all software companies) take advantage of their closed sources to hide all kinds of weird shenanigans and/or patent infringements in there without anyone being able to tell. Giving access to the sources would be more trouble than is worth for them.

To some extent it would have been nice to say, if you want to run old games, get an old computer, install an old OS on it (and just keep it offline). This is fine and would actually be my personal solution and works well for retro gaming; Megadrive, DOS, SNES, eveything.

So just as I've finally managed to get rid of my dual boot setup with Windows I'll have to yet again dual boot, this time with an older Linux system, just to be able to run my "old" games like e.g. the various Bethesda titles from 5 years ago? Seriously? And all this for no better reason than for the sake of a 64-bit purism crusade that is being championed by mostly clueless people (I'm not referring to you) who don't even understand the difference between 32-bit and 64-bit and the need to have both in order for a system that does not exist in its own little bubble (i.e. for 99% of the computers out there) to function properly?

How did you get a headache by me spewing nonsense about a subject that I clearly do not understand?

'Nuff said.

One final note: as long as Windows fully supports 32-bit as a first-class citizen, and as long as Windows is the leading player by far in the desktop OS market, and as long as hardware and software vendors cater their products according to the needs and trends set by said leading player in the desktop OS market (a.k.a. they still use 32-bit for their apps/libraries/installers because there is simply no need for them to do otherwise), and as long as having 32-bit libraries in an otherwise fully 64-bit system does not hamper said system in any way, then Linux should and will have to keep its 32-bit support. Anyone saying the opposite are either utterly (even if benignly) clueless, or their interests are opposed to those of Linux, whatever they may be saying in public to try and prove otherwise.

Of course, that does not mean that Linux shouldn't be looking into ways to provide 32-bit support without having to keep around the 32-bit libraries, because if and when Microsoft decide to deprecate 32-bit, we can be sure they're not gonna be warning us about it in advance so we can prepare.

[the_scx]

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.

You have absolutely no idea what you are talking about. It is kind of funny, because I have Steam and PlayOnLinux installed from RPM packages on x86-64 EL7 (RHEL 7 and CentOS 7).

https://centos.pkgs.org/7/nux-dextop-x86_64/steam-1.0.0.49-1.el7.i686.rpm.html

https://centos.pkgs.org/7/rpmfusion-nonfree-updates-x86_64/steam-1.0.0.61-1.el7.i686.rpm.html

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.

Again, bullsh*t.

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.

So what are these packages (more than 1000) doing in RHEL 8?

https://pastebin.ubuntu.com/p/YcZ79Yyqpx/

Nobody intends to abandon multilib/multiarch support in the near future. Neither Red Hat, nor SUSE, nor Canonical, nor Debian, nor Arch, nor Mageia, nor OpenMandriva. Literally none of the major players are going to completely drop support for i386.

I don't care about macOS (yes, macOS, because OS X is dead for a long time). They have been breaking compatibility for many times.
They have already abandoned support for legacy applications written for Mac OS <= 9 (Classic Environment) and PowerPC software (Rosetta). What is more, Apple dropped dedicated support for X11.app (although it should still be possible to install XQuartz). And a lot of programs written for e.g. OS X 10.4 Tiger doesn't work on macOS 10.14 Mojave for other reasons.
And now, they are going to drop support for i386 in macOS 10.15 Catalina. What is worse, they have already deprecated OpenGL and OpenCL, so they can disappear at any moment. As you can see, there are reasons why the Apple platform is not suitable for collecting games.
Do you want a mess like this in Linux? Because I definitely not. Linux was supposed to be better, without telling people whose applications they need and which they don't. But because of people like you, we have things like the last Canonical drama.

So, why are you talking about topics that you are clueless about? What is this all about? Do you like to make fun of yourself in front of others? Is this a fetish or something? Tell me, because I'm really curious about this.

[anarki2]

Speak for yourself, clown.

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.