Please provide a 64-bit package
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 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
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
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.
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.
@andyceo according to the blog post @jidlaph posted there's going to be a 64bit eventually. Close this issue?
@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 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.
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)
Steam should be able to install native 64bit games
@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.
@john-valve: the multi-arch solution would be:
- ship a native amd64 Steam, depend on the proper libraries /to run steam/ (ie. just amd64 libraries)
- 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. ;-)
@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.
@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).
steam64 dummy package now available in repository.
@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.
@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.
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.
Need full 64 bity port! I use 64 bit Linux from 2008. Why Value create Steam from past?
@stalkerg 32-bit is compatible with more systems (both 32- and 64-bit) but 64-bit only works with 64-bit.
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.
A 64-bit package would be nice, wouldn't have to fuck around with emulation libraries as much.
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!
32 bits systems cant run anything new of games anyway!
Is that so?
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.
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.
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/
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.
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%.
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.
I don't care much if steam is 64 bit or not, but I think the source engine and games should be 64 bit. 64 bit not only would let these games use my 16 GB of RAM (cutting down level load time, if nothing else), as I understand it amd64 also added registers and instructions which might speed up execution. Also the new consoles have >4 GB RAM and use 64 bit, so one can expect PC games to do the same in the near future.
They are probably working on it. They know they have to minimize the technical dependencies on the OS. And pulling 7439473829 32bits libs is not going to help them.
Personal opinion: I don't know if they're doing it, but based on the stats of the Steam Machines and the fact that SteamOS is a 64-bit system, I'd venture to guess that a 64-bit client (if nothing else) might be somewhere on the agenda.
I dont think so schism.
To be fair, SteamOS being 64-bit means there's a real good chance that Steam is going to become 64-bit too. And with the steam-runtime you don't actually need that many architecture dependent libs installed anyway, since it contains most of them.
And deary me it would be nice to not juggle as many multiarch packages, since Steam is literally the only non-64 bit package I have installed.
Some Games are 64bit some games are 32 bit. Steam 64 bit and steamos not supporting 32bit is long long away.
Ubuntu 16.04 might be the last ubuntu with 32bit images. Shipping steam platform with 64bit packages should be considered as an important issue. Time to move now.
source: https://bryanquigley.com/crazy-ideas/still-running-32-bit-ubuntu
@gracicot there appears to be some confusion here, on x86, the current choices are a distro shipping with a 32bit environment, a 64bit-only environment, or a 64bit multilib (with 32bit as well) environment. 64bit Ubuntu is the last of these choices, which provides the libraries for 32bit applications in addition to 64bit libraries.
Ubuntu no longer shipping a 32bit install media is a completely different topic from which architexture steam itself is compiled for. It will be an issue if and when Ubuntu decides to no longer be multilib, then this would be a relevent.
Yeah, but you still need to include multilib. I'm on arch and I had to bloat my whole installation with a load of multilib package only for steam. It's quite annoying and there no reason why steam should stick to a so old tech.
Many games ship only 32bit binaries, so multilib support is still needed.
Even if the Steam Client was to ship a 64bit version, multilib support
would still be needed.
On Wed, Oct 22, 2014 at 12:33:22PM -0700, Ruedii wrote:
Many games ship only 32bit binaries, so multilib support is still needed.
Even if the Steam Client was to ship a 64bit version, multilib support
would still be needed.
Multilib is a dirty work around for old unmaintain 32bits apps. Steam should
switch to 64bits on PC for good and game devs should provide a x86_64 build or
use the 64 bits edition of their runtime. Stop this non-sense, please!
Sylvain
Valve can't really approach all devs who have only provided a 32-bit application and demand 64-bit. It's also not just unsupported games. Introversion Software has had people asking for 64-bit game clients since at least as far back as 2005.
Also, there are tons of largely abandoned games on Steam. The devs have finished development and moved on.
On Wed, Oct 22, 2014 at 03:36:09PM -0700, Joshua Embrey wrote:
Valve can't really approach all devs who have only provided a 32-bit
application and demand 64-bit. It's also not just unsupported games.
Introversion Software has had people asking for 64-bit game clients since at
least as far back as 2005.Also, there are tons of largely abandoned games on Steam. The devs have
finished development and moved on.
The steam client can be native 64bits and have a filter based on 32 bits libs
available or not on your gnu/linux distro.
Sylvain
That's an even dirtier workaround than the accepted method of multilib....
It's not dirtier: It's a matter of who is going to do the work. Distro integrators must handle and manage all the additional system related 32 bits libs, or, valve does port its client to native 64bits and does the code to handle "clean" 64bits systems. If valve does the work, it means detection code, and code to filter out 32 bits only games on "clean" 64 bits systems. That would be another parameter in game features, and I can reasonably guess that making it right in the entire valve infrastructure, it's some significant work. In the case of distro integrators doing the work, the amount of work depends on the numbers of components needed by games and the steam client/runtime. I don't know how many components must have their 32 bits counter part to be compiled and installed though (I may have missed the list).
"native 64bits and does the code to handle "clean" 64bits systems. If valve
does the work, it means detection code, and code to filter out 32 bits only
games on "clean" 64 bits systems."
This makes no sense and unless you can substantiate this this claim is
utterly false.
Live long and prosper,
Christ-Jan Wijtmans
https://github.com/cjwijtmans
http://facebook.com/cj.wijtmans
http://twitter.com/cjwijtmans
On Thu, Oct 23, 2014 at 4:14 AM, Sylvain BERTRAND [email protected]
wrote:
It's not dirtier: It's a matter of who is going to do the work. Distro
integrators must handle and manage all the additional system related 32
bits libs, or, valve does port its client to native 64bits and does the
code to handle "clean" 64bits systems. If valve does the work, it means
detection code, and code to filter out 32 bits only games on "clean" 64
bits systems. That would be another parameter in game features, and I can
reasonably guess that making it right in the entire valve infrastructure,
it's some significant work. In the case of distro integrators doing the
work, the amount of work depends on the numbers of components needed by
games and the steam client/runtime. I don't know how many components must
have their 32 bits counter part to be compiled and installed though (I may
have missed the list).—
Reply to this email directly or view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-60183821
.
A better solution may be to provide a chroot environment to run 32bit games
in.
@Ruedii
A 32bits chroot does not change anything: either the gnu/linux distro integrators or valve do/does the job as described previously. It's a choice: either steam runtime is more complex and technically costly or gnu/linux distros/cpus are heavier/more technically costly.
The real dirty part is in the silicium: that hardware 32 bits mode should not be there on 64 bits cpus. The x86 hardware real mode is already a waste and it's dirty. Now with 3 hardware modes... even dirtier.
Honestly, and this is not a negative criticism, a large part of games available on Steam requires a powerful and recent hardware, which probably run a 64-bits system. 32-bits support should be provided as backward compatibility.
In Linux world, applications are built for each architecture, we generally don't miss this kind of issue where a linux app only provide a binary for one arch only. And multilib is a mess to maintain.
Ping, :+1:
Disclaimer: Don't get me wrong, I like steam!
As a gentoo user, this is an issue for me.
In general, I like how I can play games on steam natively these days, but I am really amazed that the the one company trying to get linux into the gaming business made an app that opposes linux-way-of-things in every way: packaging of executables in APT, 32bit client only, updates done through the client and not the package manager, no official support for distros, branded look and feel, hack bash script launchers, etc.
I keep it in chroot because I don't trust it, and it's a pity.
@stgpetrovic
I'm a Gentoo user myself, and I'd love to see a 64-bit Steam client.
But I feel like I can't agree with all of your points. Yes, it's a bit sad that they've baked in APT into it, but that's understandable since we're using the version they designed for Ubuntu 12.
And Steam is a package manager itself, so being updated through another package manager sounds like a strange solution. Not to mention the fact that it wouldn't work anyway, since Steam installs per-user.
I'm a fan of the bash launchers, since they provide some transparency into what's actually going on as Steam launches the games. Something that's helped me debug and fix several issues, where if they'd done launching directly through Steam I would've been stumped.
Though I wonder if Steam will look into xdg-app when that goes stable, it feels like they'd fit perfectly together.
@ace13
I have nothing against bash launchers, in fact I also like them, but I said "hacky", meaning badly written, deleting your root partition on occasion :)
Well it's not sad that we are using data from .deb in a gentoo overlay, it's sad that they've only designed an Ubuntu12 version.
There's no problem with having a package manager manage package managers, in fact you can find yum, or archlinux's pacman in portage.
"Steam installs per user" is not a linux way; you can have per-user profiles in ~/.config, you can do as any other application does - this is my point. If they have to keep closed source approach (I'm not going to troll), they can perfectly well keep a binary package like firefox-bin, and behave like a normal linux application. If they opensourced it, I'd volunteer to improve it :)
@stgpetrovic
I guess I misunderstood which part of the bash launcher argument you were complaining about, sorry.
And yeah, they've been a bit shoddily written before, but since Steam runs entirely as your user it can't manage to remove any system components at least. Which is not a very good argument, I know
Anyway.
Yeah, you can install both yum and pacman from portage, but I think you'll find that the recommended way to keep either of them updated would be through themselves - not through portage.
What would be nice though would be to see steam put more of its data system-wide, since Steam takes up a lot of space right now. Especially on multi-user machines. But I guess that's not really part of this issue.
For them to be able to do proper system-wide usage they'd most likely have to write a steam daemon that you communicate with over dbus or sockets, and let the steam daemon manage all the installing/updating tasks.
Actually, @ace13 some the delete bug hit a few people. The script had a bug in it and they were running as root (for some ungodly reason or another).
package manager manage package managers
IMO, a better example (and model to follow, natch) is my old friend g-cpan (or jauhien's g-sorcery). Make it possible for my system PM to cleanly interact with the domain-specific PM and I'm a very happy camper.
+1. Would very much like to have a 64 bit version. Right now I'm on Arch, and using a custom repository to get all the packages I need to turn of the Steam runtime. The sad part is that the 64 bit versions are in the official repositories.
It was a big mistake to make 32bit client.
+1
The unity engine will provide their editor for 64 bit only. 64 bit is not new, most of computers are 64 bit and 32 bit becomes slowly deprecated. Steam would be in a way better shape with 64 bit executable, at least for the client and store. source: http://blogs.unity3d.com/2015/08/26/unity-comes-to-linux-experimental-build-now-available/
:+1:
+1 im on a slower laptop running arch. All i want to do is stream games from a windows box to my laptop.
A native 64bit client would save the day. 32bit games need multi-arch support on 64bit, thats fine... would be nice if steam has some tags for 32, 64bit, ARM, so i can filter them based on what platform im running, thinking steam builds for cellphone or tablet.
+1 for filters based on 32bits builds/64bits builds/CPU builds (all below a multi-platform OS category like gnu/linux|steamos).
It would be nice to simply include a more complete 32 bit steam runtime on
the version packaged for 64 bits to save the hassle of installing multilib
on the system. The kernel would still require multilib support but the
system libraries wouldn't.
I would recommend doing this by having a steam runtime and steam runtime
complete. The later would only require the kernel and no base libraries.
A system flag could report which to run.
On Nov 14, 2015 8:47 PM, "Sylvain BERTRAND" [email protected]
wrote:
+1 for filters based on 32bits builds/64bits builds/CPU builds (all below
a multi-platform OS category like gnu/linux|steamos).—
Reply to this email directly or view it on GitHub.
On Sun, Nov 15, 2015 at 08:17:31AM -0800, Ruedii wrote:
It would be nice to simply include a more complete 32 bit steam runtime on
the version packaged for 64 bits to save the hassle of installing multilib
on the system. The kernel would still require multilib support but the
system libraries wouldn't.
It's actually what "anything binary" (32 bits or 64 bits) should tend to on
linux based OSes.
It depends where you draw the line for "system ABIs":
- base binary ABI, ELF file format, with a effort to avoid complex/bloat
sections (maybe a static libdl...). - sound: libpulse (erk... ABI seems to be a "moving target"), libasound (alsa)
- GFX/3D: tricky, since xorg client libs may include code aware of current linux
ABI for hardware acceleration which seems not that stable. - input: direct on linux devices or via the various x11 input
methods/libinput(wayland).
Using GLX for a.graphics should reduce incompatibility a small cost when
allocating graphics buffers.
Pulse audio is socket compatible with older libpulse versions, and you
could even run a client level server that connects to the system pulse
server.
The trick is, like other chroot environments, to limit features that might
cause incompatibilities.
On Nov 15, 2015 8:06 PM, "Sylvain BERTRAND" [email protected]
wrote:
On Sun, Nov 15, 2015 at 08:17:31AM -0800, Ruedii wrote:
It would be nice to simply include a more complete 32 bit steam runtime
on
the version packaged for 64 bits to save the hassle of installing
multilib
on the system. The kernel would still require multilib support but the
system libraries wouldn't.It's actually what "anything binary" (32 bits or 64 bits) should tend to on
linux based OSes.
It depends where you draw the line for "system ABIs":
- base binary ABI, ELF file format, with a effort to avoid complex/bloat
sections (maybe a static libdl...).- sound: libpulse (erk... ABI seems to be a "moving target"), libasound
(alsa)- GFX/3D: tricky, since xorg client libs may include code aware of current
linux
ABI for hardware acceleration which seems not that stable.- input: direct on linux devices or via the various x11 input
methods/libinput(wayland).—
Reply to this email directly or view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-156884343
.
Using GLX for a.graphics should reduce incompatibility a small cost when
allocating graphics buffers.
if glx/opengl are system deps. Their APIs seems stable or at least discoverable
safely (for opengl).
Pulse audio is socket compatible with older libpulse versions, and you
could even run a client level server that connects to the system pulse
server.
Pulse socket API seems quite unstable then quite a moving target compared to
alsalib/alsa userland APIs.
The trick is, like other chroot environments, to limit features that might
cause incompatibilities.
i.e. where to draw the line for system ABIs. The minium, the better.
+1
+1
This would enable Openelec to have a steam add-on and would create the ultimate home theater setup!
http://openelec.tv/
+1
Completely eliminating 32bit support on 64bit steam would be stupid.
Many games still use 32bit binaries for one reason or another. Steam already includes a partial 32bit CHROOT and completing it would not be that difficult to provide support for systems with no 32bit libraries. The only issue is you would require SHM support for GLX-SHM extension in order to fully abstract the OpenGL functions without major penalty.
As of real mode support, 64bit Linux doesn't support real mode, there is no 3 level support. Real mode is handled through a VM library, the same one used on ARM systems to run x86 firmware code and ONLY used for certain hardware tasks when there is no other option. About the only thing such real mode emulation is used for on a 64bit Linux system is VESA 1.x video mode switching and VESA 2.x video initialization. (VESA 3.x does not need real mode at all.)
DOSBOX and DOSEMU use their own real mode emulators (instruction mangler type or GIT emulator depending on your build) as does Wine because real mode of any form cannot be accessed from non-root users.
Its 2016 and still no x64 client. Im using x64 only Gentoo for 10+ years, when Steam came out for a Linux with some dirty hacks I managed to convert my Gentoo to multilib. Year and half ago I removed Steam from Linux installation because of bad game ports, bad client and I got tired of handling multilib, converted Gentoo to x64 only, and went back to playing games on Windows (they run better, they look better).
Valve mistake is using 32bit in first place, all game ports where new ports, so it was possible to force all developers to make 64bit ports by providing 64bit client only. Did Valve made 32bit client to be able to support at that time non-existent 32bit Linux games? 4 (and more) years ago majority of Linux installations where 64bit, with tendency of increased adoption. Second mistake is no quality control, on 10 over-promises there where 1-2 under-deliveries. Third mistake, Valve chose 2 bad distributions to support by default and to base its SteamOS on. How is Valve going to handle Wayland/Mir)
Anyway. I would be happy with 64bit client that can only play 64bit games (non-64 bit games are either junk or inferior ports), just add Linux 64bit in Library drop-down list.
Sorry for bad English.
+1
64-bit please
Oscar are you trolling? There isn't a single arm game on steam
On 24 Feb 2016 12:57 p.m., "Oscar Rivera" [email protected] wrote:
YES!!!
64-bit please.
It's 2016 and x86 is slowly being replaced by ARM while the real
horsepower (especially for games) is in 64-bit.
....... and please don't tell me that my next game will be shipped to me
on a floppy disk..... and delivered by donkey.—
Reply to this email directly or view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-187974009
.
I agree completely.
Game developers should be encouraged to release their binaries in 64bit.
This should include marking 64bit enabled games in the store by platform
(probably a suggestion to go elsewhere) and having the client in 64bit.
64bit binaries are a lot easier to implement in Linux, and tend not to
introduce bugs.
64bit tend to run slightly faster due to access to more general-purpose
registers, and more operations being available to general-purpose
registers. (Many functions previously only available to the EAX/AX/AL/AH
accumulator register in 32bit are available to all General Purpose
registers in 64bit mode.)
Other advantages of 64bit on all platforms include access to a larger video
memory block, and access to more memory without utilizing paged access or
pageflipping.
On Tue, Feb 23, 2016 at 7:18 PM, joshua [email protected] wrote:
Oscar are you trolling? There isn't a single arm game on steam
On 24 Feb 2016 12:57 p.m., "Oscar Rivera" [email protected]
wrote:YES!!!
64-bit please.
It's 2016 and x86 is slowly being replaced by ARM while the real
horsepower (especially for games) is in 64-bit.
....... and please don't tell me that my next game will be shipped to me
on a floppy disk..... and delivered by donkey.—
Reply to this email directly or view it on GitHub
<
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-187974009.
—
Reply to this email directly or view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-187981817
.
I think they know about the benefits. They probably just aren't ready for a
full rewrite of the client.
On 24 Feb 2016 9:35 p.m., "Ruedii" [email protected] wrote:
I agree completely.
Game developers should be encouraged to release their binaries in 64bit.
This should include marking 64bit enabled games in the store by platform
(probably a suggestion to go elsewhere) and having the client in 64bit.64bit binaries are a lot easier to implement in Linux, and tend not to
introduce bugs.64bit tend to run slightly faster due to access to more general-purpose
registers, and more operations being available to general-purpose
registers. (Many functions previously only available to the EAX/AX/AL/AH
accumulator register in 32bit are available to all General Purpose
registers in 64bit mode.)Other advantages of 64bit on all platforms include access to a larger video
memory block, and access to more memory without utilizing paged access or
pageflipping.On Tue, Feb 23, 2016 at 7:18 PM, joshua [email protected] wrote:
Oscar are you trolling? There isn't a single arm game on steam
On 24 Feb 2016 12:57 p.m., "Oscar Rivera" [email protected]
wrote:YES!!!
64-bit please.
It's 2016 and x86 is slowly being replaced by ARM while the real
horsepower (especially for games) is in 64-bit.
....... and please don't tell me that my next game will be shipped to
me
on a floppy disk..... and delivered by donkey.—
Reply to this email directly or view it on GitHub
<https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-187974009
.
—
Reply to this email directly or view it on GitHub
<
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-187981817.
—
Reply to this email directly or view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-188139280
.
:+1:
It wouldn't be a full rewrite. Just a recompile. A big chunk of QA work
needs to be done again, but otherwise.there is not much that needs to be
done. Linux64 is a lot easier of a transition than Win64. (Win64 is hell
to transition to.)
+1
Thank you Samuel for your helpful comment.
On 30 Apr 2016 11:12 p.m., "Samuel Williams" [email protected]
wrote:
+1
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-215956363
@not83 Dude, my comment was so unhelpful, I don't even know where to begin. But, I'm very similar to many other posts here. running a 64-bit system, prefer not to install 32-bit libraries just or one app, etc, etc. Since this issue has been open since 2012, it might take until computers use 128-bit addressing and registers before we see steam finally support x64. Or perhaps we will all be using the Mill architecture by that point?
Or maybe someone needs to make a Docker image for Steam on Linux :D
You know what, a Docker image for the Steam client sounds like a beautiful idea, why haven't I thought of that myself?
if someone could make a container for steam and wine so my gentoo system wont be riddle with multilib would be awesome.(although i can easily live without wine)
Container function was my thought as well.
With more games moving to 64 bit and some Linux distros planing to drop 32 bit, this is a must have.
+1 for 64 bit client
+1 for 64 bit client
Does that make it a 65 bit client?
Please don't waste people's time with a "+1" comment, just subscribe for
notifications and/or use the thumbs up or other reaction. That's what
they're there for.
On Sat, May 28, 2016 at 8:12 PM, Samuel Williams [email protected]
wrote:
+1 for 64 bit client
Does that make it a 65 bit client?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-222335547,
or mute the thread
https://github.com/notifications/unsubscribe/AFRxXYBATLWLZcGreeN0ke8HRSmpHmB8ks5qGNnQgaJpZM4AU5Ey
.
Now that there are moves by kernel and distros to abandon 32bit all together, can we please finally get a 64bit version? My steam installs seem to break when self-updating due to 32bit lib issues, really rather not have to deal with this in 2016.
My steam keep on installing unwanted 32 bit libraries, and effectively make it unable to launch anymore at every... Single... Updates. I don't understand why 32 bit only applications still exists. For how long processors are 64 bit? A really really long time. If a program is well made, they should be no differences between building a 64 bit binary and 32 bit one except some compiler arguments and packaging.
Not just that, the whole client on Linux is a giant hack.
function detect_platform()
{
# Maybe be smarter someday
# Right now this is the only platform we have a bootstrap for, so hard-code it.
echo ubuntu12_32
}
Really? Currently, for people who want to play 64-bit games, it is a requirement (thanks to steam-client) to have 32bit libX11/libGL. A better idea would be to release a 64bit steam client with the option to "opt-in" to a 32bit bootstrap.
An even better option is to opensource the client and let the community do the job
Well currently a big chunk of the steam runtime is open source.
You can launch any Steam game in Linux from steamcmd, so we could make our
own x86-64 client around steamcmd and an embedded browser. I wish they
would make a lightweight Steam Authentication Services deamon so we could
make it even lighter.
On Aug 21, 2016 2:38 PM, "ekaris" [email protected] wrote:
An even better option is to opensource the client and let the community do
the job—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-241273820,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADBV6STNzjKPxyXe6q86YzroQA4qEu30ks5qiJsGgaJpZM4AU5Ey
.
@Ruedii Are you sure you can launch any steam game from steamcmd? How? I thought this is possible only from the Steam client. Also, isn't steamcmd also 32bit?
steamcmd, as downloaded 5 minutes ago:
me@linuxbox:~/steamcmd$ uname -a
Linux linuxbox 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 x86_64 x86_64 x86_64
GNU/Linux
me@linuxbox:~/steamcmd$ file linux32/steamcmd
linux32/steamcmd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.34, BuildID[sha1]=17188c02dec11be2af104afd625f39a2c89b54c7, not stripped
Going to go with not 64-bit based on this. Another test: Windows 10 (WSL) can only execute true 64-bit code. So this happens:
me@linuxbox~/steamcmd$ ./steam.sh
Running Steam on ubuntu 14.04 64-bit
STEAM_RUNTIME is enabled automatically
Unpack runtime failed, error code 1
./steam.sh: line 473: /home/me/steamcmd/ubuntu12_32/steam: No such file or directory
Installing bootstrap /usr/lib/steam/bootstraplinux_ubuntu12_32.tar.xz
Running Steam on ubuntu 14.04 64-bit
STEAM_RUNTIME has been set by the user to: /home/me/steamcmd/ubuntu12_32/steam-runtime
Error: You are missing the following 32-bit libraries, and Steam may not run:
libc.so.6
/home/me/steamcmd/steam.sh: line 755: /home/me/steamcmd/ubuntu12_32/steam: cannot execute binary file: Exec format error
As soon as it tries to start, it starts spewing graphical error messages about missing shared libraries.
steamcmd ships with its own core 32bit libs as it does not need libGL/libX11.
Contrary to what @Ruedii said, I can not find an option to launch steam games via steamcmd, you can download them, but not launch them (unless they have NO steam integration and you directly execute the games binary).
It's complicated. There is a separate set of steamcmd routines to handle your login, then you have to set up an environment with the added steam support libraries and all the other proper stuff.
It's possible, but it's the sort of thing you need to write scripts and a GUI to handle. It's not something that is practical to do from the command line (even though it is possible to, possible and practical are two different things.)
Furthermore, the SteamCMD program is 32bit but it's got it's own libraries and doesn't rely on X11 or GLX. This means you can run it from a 64bit GUI program without having a huge number of 32bit libraries installed.
Down with 32bit!
64 Bit Arch has been out for a long time as it relates to Technology, far to long, that we still have to deal with developers building 32bit apps.
Let 32bit die!
Please make a 64bit pkg Valve!
I have no care or plans ever again for Multilib in Linux, so I won't be installing Steam until a 64bit package comes out.
Down with 32bit!
While that would be nice, not going to happen for a long time. You would be breaking most of the library, not to mention myriads of OS compatibility.
I have no care or plans ever again for Multilib in Linux, so I won't be installing Steam until a 64bit package comes out.
Ok, then have fun :)
You would be breaking most of the library, not to mention myriads of OS compatibility.
@ProfessorKaos64 incorrect statements are incorrect.
@cjwijtmans explain then. You added nothing to the discussion with your statement. Plans are for distros to drop 32-bit CPU support, meaning you would not be able to install the OS as a 32 bit system. This does not mean multi-lib (.i.e. i386) packages are being done away with.
Without there being CPU support, software support is going to dwindle though. Won't take long before only 64-bit applications remain a viable solution, already lots of software and even several drivers today that simply won't run on 32-bit platforms.
Come to think of it, I suppose Steam could be made happy to run inside a Flatpak, that would probably solve most of the short-term 32-bit issues.
There are no 32bit issues.
Plans are for distros to drop 32-bit CPU support, meaning you would not be able to install the OS as a 32 bit system.
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.
This does not mean multi-lib (.i.e. i386) packages are being done away with.
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
hl2_linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.32, BuildID[sha1]=817971d228a59319b6e0296084d041a814675cc4, not stripped
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:
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
hl2_linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.32,
BuildID[sha1]=817971d228a59319b6e0296084d041a814675cc4, not stripped—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-261758490,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC0jc-Y5nvE1ZXRkklybJPsp2uJnLwMGks5q_82tgaJpZM4AU5Ey
.
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:
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++
Wrong. c++ runtime should be statically linked at the application level. c++
ABI is a pile of s**t (I'm assuming 100% of my words on this matter). Not to
mention that a proper and modern c++ compiler frontend/runtime are bare
insanities to get to work reasonnably.
Also, application binaries should be linked statically to their libgcc related
code.
The real steam platform ABI would be ELF libs with minimal sets of explicit
simple symbols.
Personally, I think the Steam runtime needs a complete update. Currently
only a few libraries have been updated, to provide compatibility with Vulkan.
Hope we get C only vulkan support libs. Because that c++ dep is really
annoying (like glsl being dependent on llvm in mesa).
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.
Pulse is really bad (big kludge). Luckily we have an alsa plugin, but as far as
I know, pulse can manage hotplugging transparently for applications and software
mixing from stereo to 7.1. With alsalib, it seems the hotplug code has to be
in the application code as well as the resampling/mixing code.
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:
30.15% Ubuntu 16.04.1 LTS 64 bit
10.69% Linux 64 bit
9.17% Linux Mint 18 Sarah 64 bit
6.59% Ubuntu 16.10 64 bit
5.33% Ubuntu 14.04.5 LTS 64 bit
38.07% Other
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" [email protected] 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
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-265292637,
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
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-267764561,
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
https://bitbucket.org/chromiumembedded/cef
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.
Upstream links
- ValveSoftware/steam-for-linux/issues/179x11 2016-12
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.)