Please provide a 64-bit package #179
Comments
|
And many bugs for build in gentoo 32 bit env. in winedows 64 bit is cut. But in Linux 64 bit is a main platform. |
|
What you are requesting is that all games have native 64bit versions so that you don't need to install 32bit libraries on a 64bit system. This sounds like something that will not happen. |
|
No, @Terminal58. 64-bit is the norm on Linux. It is not 'something new'. Windows is that nonsensical OS that has to keep 'backward-compatibility'. Also, Steam is not setting any standards across anything. If anything it is breaking standards as it continues to use its own 'look-and-feel'-type GUI, only supports PulseAudio for sound, a non-standard installation process (requesting the user to Wine has 64-bit support now even, better support than actual Windows considering Wine in 32-bit mode on a multi-arch Linux system can still run 16-bit apps. I think many users will stick just with running Steam on Wine. Gentoo has had 64-bit support since 2006 if not earlier. |
|
I think this is not a big problem. Multiarch is expanding, Debian Wheezy will support it, Ubuntu already does. There are some packages not multiarch-aware, but that's mainly their maintainer's fault. E.g. on Debian, there's wayland 0.85 not multiarch-aware (see issue) in repos which is blocking multiarch installation gtk3 3.6 (experimental) through mesa, although there is a multiarch-aware version in their git. |
|
Distros have stubbornly insisted for years on making multiarch a serious pain in the rear. Arch, thankfully, has had first-class multiarch for probably a couple of years now. While multiarch support is improving, I don't think it's a real answer to the issue. @Tatsh: You'll get no real benefit running the 32-bit Windows binary in WINE on your x64 Linux box. I expected WINE's performance to be superior to the native TF2 build at least at first, but so far the native build is much smoother. Don't think there are many people who are going to be better off on WINE. |
|
You say that 'distros stubbornly insisted for years on making multiarch a serious pain in the rear'. Multi-arch is a temporary solution to the problem of compatibility with older binaries. Keyword is older (especially ones we do not have the source to, hence cannot fix ourselves). This is new and so there is nearly no excuse to not provide a compatible 64-bit binary here. Even Rarsoft provides a compiled 64-bit binary of RAR: http://www.rarlab.com/download.htm. Gentoo has provided multi-arch as default 64-bit version for a very long time and still does. Generally it has worked very well but it is not something easy to maintain nor easy to keep 100% compatible with every random binary someone grabs (like Steam, or Amazon's MP3 downloader program a while ago). Having a chroot is also a cumbersome solution hence it is rarely chosen (I have gone this route before with PCSX2). @sjuxax We are probably not going to see very many big titles as native ports on Linux until some form of D3D is supported in X11 or Wayland (of which there is already some support for D3D11 in Wayland but it is experimental). Developers do not seem to want to learn GL when it comes to PC. And also, many things would have to be 'standardised', such as audio API. But you ought to know that many users on Linux have personal preferences they will not give up even for a game. Strangely enough, Wine wins here. In Wine, I can choose ALSA no matter what. I am not forced into using PulseAudio as many binary-only apps have often chosen to do (including Steam). |
|
Well I'm glad I've stimulated some debate, if nothing else! In terms of hardware support, the only obvious advantage I can see of Steam being 32-bit is that it will support Atom powered netbooks. I don't think that is going to be a significant market for Steam, and IMHO not a good enough reason for not providing 64-bit package - this is 2012! Unfortunately Ubuntu still recommends the 32-bit version for download, presumably because it's the safer option for those who don't know which to use. So there is probably a significant installed base of potential Steam users who would need to reinstall Linux to use a 64-bit package. So hopefully Valve will be able to provide support for both 32-bit and 64-bit Steam, just like almost everyone else does for their Linux software! |
|
There's no argument in saying you want a 64 bit Steam binary to get rid of 32 bit libraries when you're gonna need them all for the games you get on Steam anyway. The only way for this to happen if we get 64 bit games as well as Steam. That said, I'll +1 this. 64 bit is the future, and if we get 64 bit games and clients on windows too there's nothing wrong with that. |
|
@biltongza You're right of course. The games and libraries should be available as 64-bit packages too. This doesn't sound like rocket science, so hopefully someone at Valve and the game developers can get their head around it? |
|
+1 and I'll also note that, much like porting in the first place, a 64-bit build can help expose dangerous assumptions and bugs in your code. |
|
@Tatsh from your first post I think you're profoundly confused about what multi-arch means. (Multiarch does not mean 64bit) Your stance that 64bit is the future and everyone must convert is just wrong. As far as the GUI not changing from the Windows version, every piece of software on Linux does not have to follow every philosophy of Linux because even forcing said philosophies is against the philosophy of Linux. Saying to Valve make a 64bit of Steam because of the short comings of Linux is ignoring the capability of Linux to catch up on Multiarch support |
|
@Terminal58 why is it wrong if everyone does convert to 64 bit? We don't need to force it but these days there is pretty much no reason to go with a 32 bit system. Back on topic, if valve only provided a 64 bit binary obviously that would be silly. There has to be a 32 bit version as well. |
|
+1 to a 64-bit steam client |
|
+1 At this point a clear deal-breaker. |
|
As I said before, even if Valve provides Steam as a 64bit application. You are still going to need 32bit libraries unless every game developer releases native 64bit versions of their games. Currently some game are 32bit only, some have 32bit and 64bit versions, and some are neither (SpaceChem uses Mono, although its broken on 64bit systems for now). Right now the biggest benefit from Valve providing a 64bit version of Steam is going to be the In-game overlay working on 64bit games which it currently does not. |
|
They said on the old blog that the only-32-bits problem is only temporary. |
|
+1 for 64-bit package. |
|
@Terminal58 Usually bugs get closed when they're fixed and not before; otherwise they're misleading for people searching for the same issue. Closing it will just cause it to be reported again. |
|
@jidlaph @Terminal58 They said on the blog: "We are using a 32-bit version of Linux temporarily and will run on 64-bit Linux later." This is ambiguous. Just because they are planning to run Steam on a 64-bit Linux distribution does not mean that they are planning a 64-bit Steam package, or 64-bit game software. They may just intend to test that the 32-bit Steam package works correctly on a 64-bit distribution. |
|
@Terminal58: Like @Wyatts said, it's not Closed because it isn't fixed. A bug should only be closed under one of two conditions: either because it is Fixed, or because it's something they Won't Fix. Just because a feature request happens to be a long-term goal of theirs doesn't mean it should be Closed. @gwvr I guess you're right, though it'd suck if that were the case. If I can run 32-bit Steam on 64-bit Debian, surely running it on 64-bit Ubuntu is far too low a bar to be worth mentioning. |
|
One thing to consider is the fact that Ubuntu still recommends 32-bit by default. Steam is still supporting Ubuntu only at this point. I don't see why they'd add 64-bit now, even though I personally would love to see this happen. |
|
If a game has a native 64bit version, will I get that version of the game when I run it through the 32bit client, or will I always get the 32bit version? There are games which I own both on Steam and independently (e.g. a lot of Humble Bundle games) which seem to have 64bit versions, and I'm wondering whether there's any difference between running them through steam and from the standalone 64bit installers. |
|
@confluence: Most 3rd-party software I've seen doesn't really play nice with the filesystem. It's pretty much a coin toss as to where stuff ends up (witness Steam itself with its own bizarre half-repo half-$HOME thing). Keeping all those games in SteamApps is tidier. |
|
Yes, it certainly is tidier -- although I see more and more games helpfully packaged as debs. Unfortunately I've discovered that the vast majority of the Humble Bundle games I've just redeemed on Steam don't have Linux versions on Steam, so I'll have to keep installing them separately. I was wondering specifically whether the 32bit client will run 64bit game versions if they exist. It does look like Steam detects your architecture and runs the appropriate game version. It seems to download both versions, though, which is kind of annoying on a slow internet connection. |
|
@confluence It depends on the game in question. Dungeon of Dredmor (which is the only Linux-native game I've installed through Steam so far) installs both 32-bit and 64-bit executables, but only runs the 32-bit when launched through Steam (see my comment on #430).
I've begun e-mailing the game companies asking to put their Linux packages up on Steam in addition to their Windows (and sometimes Mac OS X) packages. I don't know if there's any specific that needs to be done on the Steam side (since it's still a beta), but I figure that the more games get on board, the more tailwind the Linux client gets - and the more the Linux client will get tested as well. |
|
We don't even technically need 64bit native binaries. We just need the dependencies in the package to provide 32bit userland support for Steam. It's a simple package modification. It shouldn't be too hard for Valve to do. There are even scripts that can do it for you. |
|
@Ruedii - as far as I can tell it is not possible to have a 64-bit .deb which has 32-bit dependencies. At least it didn't work when I tried it. And I don't see how this solves the original issue anyway (which is that people don't want to install "a gazillion 32-bit packages" on their 64-bit systems) |
ghost
self-assigned this
|
There are no 32bit issues.
Wrong. Support means support not a ban. And if by chance a distro decides to drop "support", nothing is stopping you from running an older version of that distro if you want to be stubborn.
Whomever said that? This is about the steam binary to be 64 bit. This has nothing to do with distro multilib or steams ability to run 32bit binaries with 32bit steamruntime support. |
|
My son often runs into problems because Steam games are only 32 bits on Linux, so they run out of address space very quickly. He has to turn detail level down low to play, and even that doesn't always suffice. Unless Steam makes a real effort to get to 64 bits - one game at a time is fine, but you have to start now! - it will simply become irrelevant, like flash games are today. |
|
Most steam Linux games I play have a 64 bit binary and a 32 bit one, but yeah steam should say that from here on only games that have at least a 64 bit binary are allowed. |
|
Yeah, disallowing 32 bit uploads starting sometime in 2017 would be a good step. |
|
Still present. I just installed a fresh copy of TF2 in Linux ... and it was 32 bits :-( ~/.local/share/Steam/steamapps/common/Team Fortress 2$ file hl2_linux My son is going to keep bugging me until this is fixed. |
|
Why wouldn't it be? They have announced otherwise On 20 Nov 2016 5:33 p.m., "Dan Kegel" [email protected] wrote:
|
|
To put it simply I WOULD make it require multilib capable kernels but not require any multilib libraries beyond the video drivers, libc6 and libstdc++ Personally, I think the Steam runtime needs a complete update. Currently only a few libraries have been updated, to provide compatibility with Vulkan. From what I can tell there are no compatibility issues for programs/games with upgrading the library versions, and it would fix compatibility issues with most current distros. The biggest library in question is libstdc++, which should be safe to just use the system library on. They should probably use the standard Debian packages instead of Ubuntu ones, simply because they have broader compatability. Finally it should either run it's own Pulse Daemon (to allow better compatibility and low-latency optimization) or it should auto-detect if pulse is present and configure to use ALSA instead if Pulse isn't there. It's a tough call whether a custom Pulse installation would be faster, because barring some authority mingling that some users wouldn't like, it will not have Real Time or High-Priority. However, it also won't be optimized for the desktop and can be configured to allow the changing of settings per-game to improve tuning sound quality and performance. A long term option for pulse would be to contribute a per-application tuning module upstream to Pulse and hope it gets implemented. I suspect Valve could leverage their relationships with Ubuntu and Debian to get this through. |
|
On Mon, Nov 21, 2016 at 01:12:53AM -0800, Ruedii wrote:
Wrong. c++ runtime should be statically linked at the application level. c++ Also, application binaries should be linked statically to their libgcc related The real steam platform ABI would be ELF libs with minimal sets of explicit
Hope we get C only vulkan support libs. Because that c++ dep is really
Pulse is really bad (big kludge). Luckily we have an alsa plugin, but as far as |
|
Just found out Steam has a hardware survey page with highly relevant information for this issue. To produce the same information I've pasted below just click "Linux version" on the table by the bottom. http://store.steampowered.com/hwsurvey/?platform=linux Here is a breakdown of the architecture information provided as of today: As you can see we can safely say over 60% of Steam users have 64-bit machines, given Valve's own internal data. This might lead to some people thinking "well 40% is still a bit 32-bit userbase" but I, myself really doubt 32-systems would be even 10% of the total, among those non-specified "other" systems. I wish they wold divulge the entirety of that data or at least more entries before grouping it. |
|
Another fun statistic, from Gaming on Linux; The amount of people using a 32-bit Linux distribution today is not large. |
|
Dropping support for 32 bit machines is not the problem. They'd do that in an instant (or if they wouldn't, they're very confused). It's the games that haven't bothered to do a 64 bit port. Dropping 32 bit support means dropping those games. They should announce that as of 1 Jun 2017, no new games may be published on Steam with 32 bit versions on any platform, and work with game developers beforehand to make sure they're on board. Older games, well, they can continue to be supported, there's not much money in retroporting them. |
|
There have been (confirmed) rumors about Valve looking at the Flatpak technology stack. Flatpak provides i386 platforms that can run such applications even on completely 64-bit systems. One can always hope. |
|
flatpak and snappy are good stuff, they'll make installing much easier. Won't solve the problem of 32 bit games running out of address space, though. |
|
yes, but things like flatpack and snappy clean up dependency hell. Still,
the Steam client should be 64bit mode, and the game developers should be
encouraged to use 64bit mode. It is just common sense. 32Bit memory limits
can be overcome by a paged heap function. However, the engine must be
heavily adapted for this, and it has performance impact making it just not
worth it.
…On Dec 6, 2016 5:24 PM, "Dan Kegel" ***@***.***> wrote:
flatpak and snappy are good stuff, they'll make installing much easier.
Won't solve the problem of 32 bit games running out of address space,
though.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#179 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADBV6bDDPp7u4VVdZm5gdiwfO6teg25nks5rFeCzgaJpZM4AU5Ey>
.
|
|
On Mon, Dec 12, 2016 at 07:22:42AM -0800, Ruedii wrote:
yes, but things like flatpack and snappy clean up dependency hell. Still,
the Steam client should be 64bit mode, and the game developers should be
encouraged to use 64bit mode. It is just common sense. 32Bit memory limits
can be overcome by a paged heap function. However, the engine must be
heavily adapted for this, and it has performance impact making it just not
worth it.
Don't forget that 64 bits is above all a way to have a clean and simple address
space management. The kernel can go really clean on this matter, and that
without issues about space.
It's the advant of memory mapping without space constraint, which allows very
clean programming and is quite hardware friendly (with proper synchronization
primitives).
See GPU programming: you map your command ring buffers, have sync ioctl or
even simpler, cache memory coherent mmio and done... drivers made simple.
And don't let me start on DMA. The day will come when PCIE northbridge are able
to DMA from device to device without going in system RAM (real death of
cross-fire and SLI).
…--
Sylvain
|
|
Porting 32-bit Linux games to 64-bit should't be difficult at all on Linux. It's largely just using a 64-bit environment to build your binary instead of a 32-bit environment. Not only do you gain additional memory benefits, but a larger variety of available CPU instructions and CPU registers for the compiler to play with. Can't see any reason why anyone would release a Linux game without a 64-bit option. It's not like we're Windows where there's a lot more involved. |
|
the wheels are slowly falling off :-) |
|
On Fri, Dec 16, 2016 at 11:36:32AM -0800, Dan Kegel wrote:
the wheels are slowly falling off :-)
This is the perfect example of complexity lock-in: highly complex open source
software is not worth much than closed-source software in terms of control.
And c++ is one of the perfect languages for that.
|
|
To clarify, Steam uses Chromium for its Steam Browser, and in March 2016 Google dropped support for 32-bit Chromium on Linux. This is probably because essentially all Linux distros and users are using 64-bit now, with 32-bit steadily becoming more obsolete every day. |
|
Not chromium but cef. Not exactly the same
Le 17 déc. 2016 15:02, "Pauan" <[email protected]> a écrit :
… @sylware <https://github.com/sylware> To clarify for others, Steam uses
Chromium for its Steam Browser
<http://forums.steampowered.com/forums/showpost.php?p=25815137&postcount=27>,
and in March 2016 Google dropped support for 32-bit Chromium on Linux
<https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/FoE6sL-p6oU>
.
This is probably because essentially all Linux distros and users are
using 64-bit now <https://www.gamingonlinux.com/users/statistics>, with
32-bit steadily becoming more obsolete every day.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#179 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB58bAPSZQ0jOYQwcH4KfEZfSNBkWT4pks5rI-t8gaJpZM4AU5Ey>
.
|
|
The sooner we just say no to 32 bits, the better :-) cef is just chromium with a few patches and small additions needed to make it useful as a library. It's open enough that you can actually (given skill) go in and fix bugs, and people do. So it's a lot better than closed source in that respect. (full disclosure: I use cef, and used to work on chrome) |
|
On Sat, Dec 17, 2016 at 08:19:37AM -0800, Dan Kegel wrote:
It's open enough that you can actually (given skill) go in and fix bugs, and
people do. So it's a lot better than closed source in that respect.
This is a fallacy: c++ ultra-complex cef/blink is no better than closed-source
software.
The level of entry on such code is artificially beefed by the complexity of c++.
(I was a c++ coder, now I hate it for many reasons, you can start with those
from Linus Torvalds, and I have more in stock).
|
|
If cef were "no better than closed source", there wouldn't be any pull requests at Just because you or I can't handle it, doesn't mean nobody can. And cef is pretty darn useful. I am really, really happy that there are smart folks out there contributing bugfixes to it. |
|
On Sat, Dec 17, 2016 at 09:51:56AM -0800, Dan Kegel wrote:
Just because you or I can't handle it, doesn't mean nobody can.
This is not what I said: c++ leads to obscure software design which creates
software monsters. This is hurting the open source software stack as it will
scare away coders, creates more complex bugs (security holes...). This is a
perfect "take over" by complexity language.
On Sat, Dec 17, 2016 at 09:51:56AM -0800, Dan Kegel wrote:
And cef is pretty darn useful. I am really, really happy that there are
smart folks out there contributing bugfixes to it.
And this is where you are wrong: c++ coders think they are smart, but they
aren't. They have the sick attitude to design as complex as possible "object
oriented" software. This is no smart, this is near mental illness.
Moreover they create a hard dependency on c++ compilers and runtimes which are
several orders of magnitude bigger than a C compiler and minimal runtime.
When you add all up. This is no compromise. This is sick and insane.
…--
Sylvain
|
|
off-topic. |
|
We will not drop support for the many games that have shipped on Steam with only 32-bit builds, so Steam will continue to deploy a 32-bit execution environment. To that end, it will continue to need some basic 32-bit support from the host distribution (a 32-bit glibc, ELF loader, and OpenGL driver library). Whether the Steam client graphical interface component itself gets ported to 64-bit is a different question altogether, and is largely irrelevant as the need for the 32-bit execution environment would still be there because of the many 32-bit games to support. |
and others
Please provide a 64-bit Steam package, so that those of us on 64-bit distros don't have to install a gazillion 32-bit packages.
(Ubuntu 12.04 64-bit here.)
The text was updated successfully, but these errors were encountered: