Valve Reaffirms Commitment To Linux While Also Releasing Updated Proton

[maxmasou]

ArchLinux surely has great support for gamers with latest video drivers, 32 bit libraries, etc..., it is also one of the most used platforms to report issues on ProtonDB, I tend to always see archlinux users also more involved in the community, maybe Valve knows this because of their stats.

You are 100% correct. But do you recomand Arch for a new Linux user? Personally I think Steam should be based on Debian stable like their OS. This way Ubuntu could include needed packages easily.

[Tomin]

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.

Previous poster mentioned Arch Linux's support for 32 bit libraries (multilib), not support for 32 bit computers or installations. Arch Linux was one of the first distributions to drop 32 bit and concentrate on 64 bit. There is community maintained version that is 32 bit though. (That's community of a community provided distribution.)

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.

I agree, although I also agree that there is little benefit to provide 64 bit Steam. Performance doesn't matter much there but it would be nicer if it didn't require multilib (or whatever happens to be your distribution's way to provide support for 32 bit software) but you usuallly have it for some other reason so it's a bit of a chicken and egg problem then. Funny thing is that Steam doesn't even fully work on 32 bit anymore.

[slalomsk8er]

As predicted. Valve need Ubuntu. Ubuntu need Valve.

Why all the drama?

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?

[oiaohm]

Stats may be 2% 32 bit but what % of 96 bit has 32 bit multilib installed? I am willing to guess 90%+

Next question, what % of those require multilib? I am willing to guesd 60-70%

We don't have to guess this debian popcon numbers, 80 percent of the debian installer AMD64 without i386 arch ie x86_64 are pure. 1/5 at best has multilib installed.

Those using Linux with Steam, Wine, 32 bit printer drivers are in the minority.

Idealism is nice when you dont have the price of practicality.

I agree because when 80% of Linux users installs cannot run 32 bit providing 32 bit is not that practical of an answer.

Many games on steam include lost source code or no financial incentive and will remain 32 bit.

Depends on how old. There are 32 bit games running in 32 bit dosbox sold on steam to Linux uses. dosbox can be built 64 bit. There are a lot of other games in the steam store that are using emulation in 32 bit that is available in 64 bit.

So I am not saying that have to make everything work. But there is a huge pile of stuff that 64 bit or is using emulation that the emulation can be changed to 64 bit. The stuff where you are changing the emulation you are not needing those games source code.

Breaking compatability on peoples purchases for no good reason is not reasonable and foolish.

Ignoring 80% of a market place is not very smart either. Maybe steam hardware survey numbers have Linux installs so low because the 80 percent look at and go I am not bothering enabling multi-lib just to use that.

As Tomin linked to https://www.gamingonlinux.com/articl...-disabled.8745 in 2016 steam client stop fully working on Linux 32 bit installs. So you have to be a idiot as Linux user to use steam on Linux and it not be a 64 bit distribution. Valve is being equally a idiot that the steam store program does not work at all on pure 64 bit distributions because those are the dominate install.

I would recommend steam splitting the steamos logo in 2. 1 32 and 1 64 bit as well as providing a 64 bit steam store client.

Maybe I have finally worked out why steam hardware survey numbers don't seam to line up with the size of the Linux population and its purely because valve is shooting self in foot with the 32 bit client.

[Jedibeeftrix]

By all means keep ubuntu as your reference static-release, but if you want a reference rolling-release too then look no further than tumbleweed.

[Scellow]

tldr; they gave up on native linux gaming

[oiaohm]

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?

And the second message Ubuntu is still proceeding forwards with 32 bit library removal long term from x86_64 installs they want everything 32 bit containerised.

All valve and wine have got with their market share level is a temporary stay of execution. The silent majority of Ubuntu users don't care about steam or wine because they don't use them. Steam and Wine users make a lot of media noise this is why we have a stay of execution of plan.

Basically being on death row and you get a stay to being executed only delays your execution does not mean you are not going to be killed off. Multi lib is on x86 is being killed off because its in the minority.

[slalomsk8er]

And the second message Ubuntu is still proceeding forwards with 32 bit library removal long term from x86_64 installs they want everything 32 bit containerised.

All valve and wine have got with their market share level is a temporary stay of execution. The silent majority of Ubuntu users don't care about steam or wine because they don't use them. Steam and Wine users make a lot of media noise this is why we have a stay of execution of plan.

Basically being on death row and you get a stay to being executed only delays your execution does not mean you are not going to be killed off. Multi lib is on x86 is being killed off because its in the minority.

Snaps and LXD enable us both to have complete 32-bit environments, and bundled libraries, to solve these issues in the long term.

Exactly things will stay for the short term as is but will be containerized and stay that way indefinitely.
The code quality of games let me be more comfortable with containerized solutions for gaming anyway.

We don't have to guess this debian popcon numbers, 80 percent of the debian installer AMD64 without i386 arch ie x86_64 are pure. 1/5 at best has multilib installed.

Those using Linux with Steam, Wine, 32 bit printer drivers are in the minority.

Can it be, that this are nearly 100% of the desktop/workstation Debian installations? I guess I never installed multilib on my servers but on all my desktops.

[r_a_trip]

I wonder what is going on with the 64 bit purism all of a sudden. Lots of noise about how everything should be 64 bit and how it is backwards to support programs written in 32 bit.

Also lots of confusion about what constitutes 32 bit support. Which shouldn't be too difficult to find out. This is about running 32 bit programs on a 64 bit OS. Not about running a 32 bit OS on a 32 bit processor.

Removing multilib support is not going to make your OS more capable. The only thing it will accomplish is removing your ability to run the vast back catalogue of 32 bit software. Which is shooting yourself in the foot. There are a myriad games worth having that have been written in 32 bit and which simply won't see an update to 64 bit. Should we just scrap them in the name of purity and modernity? Also, what is wrong with being able to run Word 97 on Wine so you can access your old Word files and (maybe) convert them to something more future proof?

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.

If there is a better way to support worthwhile legacy software, sure, explore the way to get there. I think it should be a community wide effort then, where all distro's and ISV's work towards a common acceptable and supported solution. Just unilaterally dropping 32 bit support, do some handwaving about "maybe containers or VM's" and telling the world that we're on our own isn't it.

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.

[oiaohm]

My guess is the Steam Windows client is probably 32 bit too. Shared source tree. Like I said earlier, on Windows that doesn't matter. The experience for the Windows end user is the same either way (roughly 96% of their clients). And before you say "Just recompile!", it's no where near that simple. When Valve is ready to move to a 64 bit client they'll probably release all supported clients as such. Till then take your 32 bit client and be grateful you even have that. There's no financial reason for Valve to support Linux. They could (very) easily get along without Linux user revenue.

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.

Can it be, that this are nearly 100% of the desktop/workstation Debian installations? I guess I never installed multilib on my servers but on all my desktops.

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.