Valve Reaffirms Commitment To Linux While Also Releasing Updated Proton

[oiaohm]

Multilib works right now. It doesn't hamper your system in any way. It is only called upon when running 32 bit software. The rest just hums along nicely on 64 bit.

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.

Oh well, at least this got me reacquainted with openSUSE Tumbleweed KDE. It's nice to be back where I started. It was SuSE Linux 7.0 that made me switch full time to Linux.

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.

[9Strike]

I hope they focus on Debian and Arch.
With Debian you basically have support for Ubuntu, Pop OS and Mint, which are great for people who want it simple.
Arch is like Debian the base for a lot of distributions (although their users usually know what their doing anyway).

[zoomblab]

Valve should better draw a line and adopt a policy to promt future productions to be 64bit. It is unavoidable. They will have to do it at some point in time.

Other than that I wonder how much of a burden is for distributions and ubuntu in particular to provide these 32bit libraries. Is it a matter of compiling with certain compiler flags? Is the process automated? Do they even create the packages themselves or do they get them from debian?

[discordian]

Valve should better draw a line and adopt a policy to promt future productions to be 64bit. It is unavoidable. They will have to do it at some point in time.

Nothing makes me happy until I can run games on a ARM or RISC-V Computer. x86 support should be scrapped altogether. (Just as we talk about some arbitrary ideas how it should be)

Other than that I wonder how much of a burden is for distributions and ubuntu in particular to provide these 32bit libraries. Is it a matter of compiling with certain compiler flags? Is the process automated? Do they even create the packages themselves or do they get them from debian?

I think the biggest issue is testing them for subtle breakage. Probably the sanest way would be to just pick 32bit libs from a older version, but unfortunately sometimes the 32/64 bit versions need to match. On debian/ubuntu the arch-independent stuff is in separate packages, referenced by all architectures - that implicitly means you can only install the matching version for 64bit or the version for 32bit (so you dont want the versions to differ)

[aronwolf]

Valve should better draw a line and adopt a policy to promt future productions to be 64bit. It is unavoidable. They will have to do it at some point in time.

Other than that I wonder how much of a burden is for distributions and ubuntu in particular to provide these 32bit libraries. Is it a matter of compiling with certain compiler flags? Is the process automated? Do they even create the packages themselves or do they get them from debian?

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.

[dungeon]

I could only say here that on Debian 10 32bit is actually never better

Everything is working, but OK devs might decide to break it in near future or maybe not in so near future

[tankenmate]

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.

Actually, installing :i386 multiarch libs doesn't do any harm to your system at all. The 32bit versions of the packages only run for programs that are linked to them. Your argument is as false as saying that having a static binary on your system that you don't run slows it down. For software that will never be ported to 64 bit (i.e. unmaintained software) 32 bit multiarch libs are the only way to get them to execute. Doing away with multiarch means it is much much harder for "normal" (i.e. non platform support) devs (and users) to install, update, maintain their systems if they use 32 bit software that won't or can't be ported to 64 bit.

Once this change goes through you won't be able to deboostrap a 32 bit chroot on your system, so you can't even bug fix your own system any more. Under this situation if you buy a new GPU you probably won't be run Wine 32 bit programs any more; where as with multiarch this isn't an issue. LXDs won't fix this issue, in fact it will make it much harder as every coder will need their own build farm and full OS 32 bit repo just to fix one lib. LXDs aren't the fix they're just a different flavour of the problem. The number of user submitted fixes will fall to zero and "many eyes make bug shallow" will be a thing of the past for 32 bit.

[oiaohm]

I could only say here that on Debian 10 32bit is actually never better

Everything is working, but OK devs might decide to break it in near future or maybe not in so near future

In another post in a different thread I screwed my debian popcon https://popcon.debian.org/ maths up.

I forgot you have a AMD64 bit system with i386 enable in popcon it counts twice. I was thinking 12 percent i386 systems was high.
i386/AMD64
22886/170889=~ 13 percent people max who have AMD64 bit Debian have 32 bit libraries installed. Popcon numbers may not be 100 percent right.

85 percent+ of the Debian AMD64 users cannot install Steam or 32bit wine by popcon. They don't have 32 bit installed.

This image at Debian shows a really scary trend for i386 on Debian. i386(your 32 bit multi lib and you 32 bit system usage) usage is on a nice constant dropping like that if nothing changes it will basically hit zero in 6 years. Yes that trend started 2014 the same year RHEL7 was released without 32 bit support. Yes the trigger was pulled on i386/x86 32bit multilib in 2014 by redhat with the release of RHEL7 and bullet is slowly killing i386 with no sign of recovery.

The amount of testing Ubuntu is getting for free using i386 from Debian parts is also dropping like this chart is.

There is no where to go with high quality assurance and keep x86-32 multilib support with the current trends.

We will be lucky if this levels out at 5% currently there is no sign that this trend is levelling off any time soon. No matter how you look at the number those who need 32 bit multi lib on debian without question are in the minority.

Yes these numbers make Valve steam client lacking x86_64/AMD64 binary support and claiming Linux support seam stupid. Not support 85+% of the userbase of platform and saying you support is kind of stupid. Worse when you work out the user base Valve is targeting in Debian is shrinking rapidly.

These numbers are not a growth in new users causing the stats to move. This is simple case the exist i386 users are disappearing as they update their systems and they find they don't need i386 stuff to get their work done.

[dungeon]

I think you interpretating these numbers really freely but also wrongly, as better count installations manually of 686, 686-pae,etc.. so 32bit kernels installed there. These are likely not multilib installs

Most of these are actually pure 32bit numbers, so are actually 32bit OS installs... something between 8% to 12% is right. Or if you like, believe it or not but to say optimally 10% people still uses Debian 32bit for real

Couple years ago that was like 15%, so number goes surely down, but it is still quite high

Popcon numbers may not be 100 percent right.

Of course, someone might use complete 32bit install but just 64bit kernels or so... it is impossible to be 100% sure there

Still, i dunno why you keep saying multilib, multilib... as most of these are just pure 32bit OS installs

[JPFSanders]

There is a problem here.

https://store.steampowered.com/hwsurvey/

Click on the OS versions and notice how little 32 bit there is. All of OS X and Linux users are 64 bit installs. There is only about 2 percent 32 bit in use by OS people is using and that is all windows. Most of that is Windows 7 that goes end of life in 2020.

You're mixing things, while there might be only two percent of windows users running 32bit windows, all of 64Bit Windows installs can run 32Bit applications.

Think carefully about that.

Remember https://www.phoronix.com/scan.php?pa...10-x8664&num=1 we stopped running these benchmarks because i686 was never winning against x86_64.

Steam Client really should be 64 bit. We should be able to run some games from steam without needing 32 bit libraries. Its been years since the steam hwsurvey has shown a 32 bit Linux user. Anyone after performance with a Linux system will not be using i686 binaries they will be using x86_64.

Again you're mixing things, the issue with 32Bit is not if a 32bit environment is faster or not than 64bit, the issue is that we need to be able to run the 32Bit applications that we do not have the source code of, and oh shock, there are applications that run fine as 32bit and that moving them to 64bits will only have a placebo effect but will cost money and effort.

I know this is hard to believe to the youngsters here but there is plenty of commercial unix/linux software in the field that requires 32bit support, generally those are running on RH boxes, because RH will never engage in stupid shenanigans like Canonical.