Please provide a 64-bit package

[gwvr]

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

[stalkerg]

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.

[arrowmaster]

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.

[Tatsh]

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 apt-get more stuff is not normal at all), and it only officially supports one distro.

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. Slackware: 2005 at least Ubuntu: 2006 or earlier

[Majkl578]

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.

[sjuxax]

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.

[Tatsh]

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

[gwvr]

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!

[biltongza]

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.

[gwvr]

@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?

[Llammissar]

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

[thomhansen]

@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

[biltongza]

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

[yamokosk]

+1 to a 64-bit steam client

[ghost]

+1 Being on Chakra, where we pretty much dropped 32 bit for good, i'd have to install 34+ (out-of-date) lib-32 packages, things like dbus, alsa, libx11, crypt, probably catalyst too. Even if I could be bothered to do this just for beta-testing one single application, I'd have to solve some "unsolvable conflicts" first.

At this point a clear deal-breaker.

[arrowmaster]

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.

[jidlaph]

They said on the old blog that the only-32-bits problem is only temporary.

[andyceo]

+1 for 64-bit package.

[thomhansen]

@andyceo according to the blog post @jidlaph posted there's going to be a 64bit eventually. Close this issue?

[Llammissar]

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

[gwvr]

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

[jidlaph]

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

[ghost]

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.

[confluence]

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.

[jidlaph]

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

[confluence]

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.

[Freso]

@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 discovered that the vast majority of the Humble Bundle games I've just redeemed on Steam don't have Linux versions on Steam

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.

[Ruedii]

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.

[johnv-valve]

@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)

[gracicot]

Steam should be able to install native 64bit games

[ghost]

@johnv-valve: There must be a way around this because WINE supports both 64-bit and 32-bit Windows applications; the 32-bit ones require 32-bit libraries. Of course, Ubuntu may not support this, but I know for a fact that Arch Linux and many other distros do.

[jidlaph]

As near as I can tell, Debian solves the problem by not providing a 64-bit version of the package being depended on. The amd64 wine depends on wine-bin*, but wine-bin is only in the 32-bit repo.

• or wine64-bin, but that's irrelevant.

[TheRealCuran]

@john-valve: the multi-arch solution would be:

1. ship a native amd64 Steam, depend on the proper libraries /to run steam/ (ie. just amd64 libraries)
2. if a game requires certain i386 libraries because it's a i386 binary, then either install a dependency package (empty package which depends on the right libraries) or package the game as a Debian package and install that or just distribute statically linked stuff (my preference would be proper packages)

If your concern is the overlay, which needs to be as an amd64 version for amd64 games and also as an i386 version for i386 games, then have those games (or the dummy dependency packages of those games) depend on the correct library package.

If your concern is communication between processes: use D-BUS (AFAIK nobody is preventing you to encrypt the data you send between processes in an attempt to stop users triggering achievements or such things manually).

If your concern is more general (how do I depend on a 64 bit system on a 32 bit library) the answer is very simple: either use dummy packages (ugly hack but possible) or ship the i386 executables in properly marked packages (field Architecture and the multi-arch fields), that way they automatically depend on the i386 libraries they need/were linked against. Short: just install i386 binary packages. On a multi-arch enabled system I can choose which binary I want, ie. I can install vim-nox:i386 or vim-nox:amd64. Usually I'd use the native version, but if a tool/game/program is only available as, say super-cool-game:i386, then I can install that.

Sorry for the long answer, but I tried to explain some portions of Debian packaging (upon which Ubuntu is based) and multi-arch. If you need support, doing the correct packaging and splitting a first good read is http://www.debian.org/doc/manuals/maint-guide/ and the Debian Policy. I'm hesitant to offer my direct help, as I'm not looking for a job and don't want to do this for free either, as Steam is not FLOSS. ;-)

[MrSchism]

@TheRealCuran, I highly doubt that they'll ever distribute the games as .deb packages (or any other type, for that matter). Steam functions as both a content delivery system and a DRM platform.

[TheRealCuran]

@MrSchism: I'm not seeing how distributing a game through Steam as a package would get in the way of being either. It might just mean some extra work if you want to support multiple distributions, hence my suggestion to use dummy dependency packages (like pbuilder is doing for installing the required build dependencies), which are relatively easy to generate on the spot, client-side. Still it'd be nicer to get a full package and with some basic work put into the tools, it shouldn't be too hard, even for different distributions (say, you want the custom executable they do as a DRM scheme, then you'd pregenerate the full package, strip out the binary and, on request, build that custom executable, put it into your template package tree, build the package and send the package down to the client, which just has to run the respective install tool on it; but again, going the dummy-package road would also be acceptable for most Steam users, I guess).

[RussianNeuroMancer]

steam64 dummy package now available in repository.

[TheRealCuran]

@RussianNeuroMancer: yes, and AFAICS it is totally pointless as I'm going to install steam:i386 anyway. An amd64 dummy package is not a solution for this bug. A native amd64 build which can install i386 binaries (e.g. games) and resolve their dependencies, would be. Ah well, it's still a beta after all.

[Ruedii]

@Johnv-valve, Actually it is, however you have to change those dependencies to depend on the multilib lib32 versions of the libraries.

It's a small change, that some automated scripts can do for you. This is how most people have installed on 64bit versions of Ubuntu.

[beoran]

I also agree that in the long run, there should be a 64 bits version of steam, and of the linux games on the platform.

However, that will take years to happen, so, meanwhile, there should be an easier way to install the right 32bits dependencies of the games automatically. I bought "Titan attacks" and it didn't run until I blindly installed all 32bits libraries I could get though ia32-libs.

[stalkerg]

Need full 64 bity port! I use 64 bit Linux from 2008. Why Value create Steam from past?

[MrSchism]

@stalkerg 32-bit is compatible with more systems (both 32- and 64-bit) but 64-bit only works with 64-bit.

[mitfik]

Please do not create software for the past! For the present is too late, so focus on creating it for the future. +1 for 64-bit package.

[ananace]

A 64-bit package would be nice, wouldn't have to fuck around with emulation libraries as much.

[cjwijtmans]

32 bits systems cant run anything new of games anyway! can you please add 64 bit binaries! so that my games can run in 64 bit to!

[ghost]

32 bits systems cant run anything new of games anyway!

Is that so?

[MrSchism]

Two things...

First, there are a ton of games still being released that are 32-bit and don't have a 64-bit equivalent.

Second, I believe we got 64-bit support back in early July.

[gwvr]

64-bit support does not equal native 64-bit software. Steam still requires the following 32 bit dependencies (on Ubuntu 12.04): gcc-4.6-base:i386 libc6:i386 libdrm-intel1:i386 libdrm-nouveau1a:i386 libdrm-radeon1:i386 libdrm2:i386 libexpat1:i386 libffi6:i386 libgcc1:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libllvm3.0:i386 libpciaccess0:i386 libstdc++6:i386 libx11-6:i386 libx11-xcb1:i386 libxau6:i386 libxcb-glx0:i386 libxcb1:i386 libxdamage1:i386 libxdmcp6:i386 libxext6:i386 libxfixes3:i386 libxxf86vm1:i386 zlib1g:i386 Steam also depends on several amd & nvidia specific packages that should possibly be recommends rather than dependencies. Ubuntu will be promoting 64-bit builds of Ubuntu desktop and server by default from this October, and I think the time is right for Valve to produce 64-bit Steam builds available too.

[MrSchism]

Ah. I wasn't 100% certain how it was running; my 64-bit OS isn't networked at the moment.

I was looking at http://repo.steampowered.com/steam/dists/precise/steam/

[cjwijtmans]

well if steam pushes 64bit as the norm then most likely game developers will follow suit or they will loose out. But i believe the information from steam surveys still states that 32 bit systems are dominant? I have no idea why there wouldnt be a 64 bit release anyway.

[MrSchism]

According to the September 2013 survey, 69.87% of users are using 64-bit variants of Vista, 7, or 8.

The most sizable group of 32-bit users comes from Win7 at just shy of 13%.

[SandonV]

Since Steam developers did not use good programing practice (like using stat64) you get problems where integers are used and not big enough total disk space, free disk space as well as issues where if your file-system uses 64-bit int for inode numbers (which anyone with XFS and > 1 TB disk should be doing) then you can't run steam at all. Steam still hasn't seem to fix issue #2610 which I reported months ago. Had steam been 64-bit this issue would not have even came up. FYI even an old game like stepmania doesn't have problems with 64-bit inodes.

There are definitely very real bugs that are occuring due to compiling it for 32-bit. I know valve didn't really consider any advantage to doing 64-bit but there definitely are advantages. Also if you ever want a game to use >4 GB of ram which will be necessary in the future.