Announcement

Collapse
No announcement yet.

Valve going to officially support Linux?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Svartalf View Post

    Heh... There's very likely to be some very nice things on the horizon for Linux Gaming within the next 6 months or so. I can't say what (NDAs...always fun with what you can/can't say...) but if the deals close, there should be at least a few happy campers.
    Well you just sold me. I mean, I never thought there would be a chance in hell that Dell would ever sell PCs without the Windows tax and yet there they are doing quite well with Ubuntu. I've always maintained that if any software company did any sort of informal investigation into Linux desktop use and demand for their software on Linux (outside of the server space) they would be pleasantly surprised. Maybe the decision makers at Valve aren't as closed off as I thought.

    Comment


    • #32
      Svartalf, if what I read between the lines of your post is correct, man! Maybe it's time for that new rig of mine soonish than what I thought

      On the other hand, I won't allow me to get too high on daydreamin' so if nothing comes to fruition the hit on the ground wouldn't be so hard. Still, as they say, hope is last to die.

      Comment


      • #33
        Originally posted by Thetargos View Post
        Svartalf, if what I read between the lines of your post is correct, man! Maybe it's time for that new rig of mine soonish than what I thought
        You'd be reading some right things into it. There's a little to appeal to the FPS crowd and a little to appeal to the RPG crowd with what might be coming up. I wouldn't get my hopes up TOO much on things yet- licensing deals are such funny beasts. NWN ALMOST became an official Linux title you could buy off the shelf- but in the end it got Nixed by one of the BoD's for the parties involved (Couldn't tell you if it was Hasbro, or Atari...). There've been other deals nuked from orbit for varying resons- this is the main reason why I state that you can't ever know what's going to happen until it's Officially Announced by a studio or publisher, LGP included in that list...

        Comment


        • #34
          Originally posted by Svartalf View Post
          You'd be reading some right things into it. There's a little to appeal to the FPS crowd and a little to appeal to the RPG crowd with what might be coming up. I wouldn't get my hopes up TOO much on things yet- licensing deals are such funny beasts. NWN ALMOST became an official Linux title you could buy off the shelf- but in the end it got Nixed by one of the BoD's for the parties involved (Couldn't tell you if it was Hasbro, or Atari...). There've been other deals nuked from orbit for varying resons- this is the main reason why I state that you can't ever know what's going to happen until it's Officially Announced by a studio or publisher, LGP included in that list...
          Darn! That's enough to get me drooling! My mind suddenly can't stop thinking about all the possibilities (and implications!), and the fact that there are clues scattered all over the place in the gaming corporate world to hint about some radical actions, but nothing concrete, nothing quite tangible, and hope that is as of yet and at some point will be an actual action... I hope I'll be able to sleep!

          First, ATI on Linux has made one of the biggest steps into the right direction (bump speed of their drivers, broaden their support for newer cards and opened their specs (wow!))

          Second, there seems to be all sorts of good news regarding Linux "all of a sudden", in many areas... and the possibility of a "shift"... It all looks really good... Hopefully not too good.

          Comment


          • #35
            Originally posted by Thetargos View Post
            Darn! That's enough to get me drooling! My mind suddenly can't stop thinking about all the possibilities (and implications!), and the fact that there are clues scattered all over the place in the gaming corporate world to hint about some radical actions, but nothing concrete, nothing quite tangible, and hope that is as of yet and at some point will be an actual action... I hope I'll be able to sleep!

            First, ATI on Linux has made one of the biggest steps into the right direction (bump speed of their drivers, broaden their support for newer cards and opened their specs (wow!))

            Second, there seems to be all sorts of good news regarding Linux "all of a sudden", in many areas... and the possibility of a "shift"... It all looks really good... Hopefully not too good.
            It's good to hear a bit of hope for Linux gaming for the future, because I was almost losing my hope for it :/ I just read a rumour that Quake Wars would be the last Linux game for ID I certainly hope that's not true.

            I think what's needed is a few games from well known developers(Blizzard, Valve,etc..) so that other publishers will get enough 'courage' to port games to Linux.

            And also, the endless differences between distros which make targeting Linux as a single platform should be taken care of.
            For example, we could have a game specific file format, with all distros supporting it, or for example use autopackage or something like that.

            I sure hope the gaming world in Linux will get better

            Comment


            • #36
              The main problem with games, is glibc, actually, rather a "a file format", that problem has been "soved" with the use of either, Loki installer or another installer. Autopackage would be nice, though.

              There seems to be a great misunderstanding about the whole idTech 5 and Linux support. Until id say something about it, I think there are chances for us getting a native client of idTech 5 games.

              Comment


              • #37
                Originally posted by Thetargos View Post
                The main problem with games, is glibc, actually, rather a "a file format", that problem has been "soved" with the use of either, Loki installer or another installer. Autopackage would be nice, though.
                You don't need autopackage- it doesn't solve the problem for commercial titles and doesn't play nicely with 64-bit x86-64 systems (LGP/Loki Install, however DOES...). However, Autobuild FROM Autopackage does solve the glibc problem in an efficient manner, especially if you couple it with Scratchbox. The nastiest problem that you face building commercial applications is with the C++ standard libraries since there's been no less than 3 ABI's in the last five or so years- it's a minefield. However, you can side-step that issue if you statically link the C++ runtimes and dynamic-link glibc against the 2.1 version of the runtimes with Autobuild. From there, you have a large range of stability, at least until the FSF crowd breaks the glibc ABI again... >:-)

                There seems to be a great misunderstanding about the whole idTech 5 and Linux support. Until id say something about it, I think there are chances for us getting a native client of idTech 5 games.
                Indeed. I suspect that most of the people that are grousing about Id not doing a Linux version are realtive newcomers to the Linux scene and don't know that Id's NEVER announced anything about Linux versions of their titles until the Beta is about to be released. Not once that I know of, in fact- and I would think I would know about it because I've been at doing Linux stuff since the 0.9.X kernel versions, when Yggdrasil was THE thing, Slackware was just picking up momentum, and SLS was the main distribution at the time.

                Comment


                • #38
                  Yes, C++ library support seems to be the most problematic part of doing native applications in Linux, that's why the companies that do have ports either statically link to whatever C++ runtime they use (Epic, BioWare) or ship a version tailored for their application (id) installed into the application's lib PATH.

                  Comment


                  • #39
                    I think, this step from valve should be credited to Ubuntu users . They have been great fanatics and don't shy out for asking support to linux. any group with money and not waiting to shout for support cannot be ignore .

                    BTW i am redhat user cause that was the stuff around in my days (10 years ago) and i have to work on it. still Ubuntu isnt bad for stuff like this. Go ubuntu fanatics!!!

                    Comment


                    • #40
                      Originally posted by Thetargos View Post
                      Yes, C++ library support seems to be the most problematic part of doing native applications in Linux, that's why the companies that do have ports either statically link to whatever C++ runtime they use (Epic, BioWare) or ship a version tailored for their application (id) installed into the application's lib PATH.
                      Add LGP to the static-link crowd. They offer a statically linked binary which is the one that's been verified. They also offer a dynamic link version with the install just in case you run afoul of problems- but it's not officially supported except when they've verified a specific configuration (and told you to use it in a FAQ or elsewhere...)... The problem with the dynamic linked version is that it doesn't QUITE work the way you expect- Linux does NOT search the PATH for .so files. It searches along the ld.so.cache specified path, which can only be dynamically overridden like you mention via LD_PRELOAD, which has it's own set of issues.

                      Comment


                      • #41
                        Originally posted by anshuman View Post
                        I think, this step from valve should be credited to Ubuntu users . They have been great fanatics and don't shy out for asking support to linux. any group with money and not waiting to shout for support cannot be ignore .

                        BTW i am redhat user cause that was the stuff around in my days (10 years ago) and i have to work on it. still Ubuntu isnt bad for stuff like this. Go ubuntu fanatics!!!
                        I use Feodra, and was too a Red Hat user from 10 years ago.

                        Originally posted by Svartalf
                        Add LGP to the static-link crowd. They offer a statically linked binary which is the one that's been verified. They also offer a dynamic link version with the install just in case you run afoul of problems- but it's not officially supported except when they've verified a specific configuration (and told you to use it in a FAQ or elsewhere...)... The problem with the dynamic linked version is that it doesn't QUITE work the way you expect- Linux does NOT search the PATH for .so files. It searches along the ld.so.cache specified path, which can only be dynamically overridden like you mention via LD_PRELOAD, which has it's own set of issues.
                        I've seen many ways of ensuring that a particular library path is seeked for in the launcher scripts for many applications. Take Neverwinter Nights' script for example, where they override the system-wide SDL library (in case it is not installed) for their own with LD_LIBRAY_PATH, placing in a higher priority their own ./lib and ./miles directories for libraries, that effectively overrides the /etc/ld.so.cache file. Some others also use LD_PRELOAD, though I'm still not sure what are the benefits of one Vs the other method, are they simply different "styles" of doing the same thing, or does one loads the symbols of a certain particular .so library and even if found another in the regular library path, that at least ensures those symbols are resolved and available for the application (maybe increasing the chances for segmentation faults or the like memory errors). I've seen LD_PRELOAD being used for overriding some application behavior (again, with NWN and some addons for Linux, like the nwuser library which sets the basic infrastructure for the game to save its data onto the user's /home directory rather than the current game directory).

                        Comment


                        • #42
                          Originally posted by Thetargos View Post
                          I've seen many ways of ensuring that a particular library path is seeked for in the launcher scripts for many applications. Take Neverwinter Nights' script for example, where they override the system-wide SDL library (in case it is not installed) for their own with LD_LIBRAY_PATH, placing in a higher priority their own ./lib and ./miles directories for libraries, that effectively overrides the /etc/ld.so.cache file. Some others also use LD_PRELOAD, though I'm still not sure what are the benefits of one Vs the other method, are they simply different "styles" of doing the same thing, or does one loads the symbols of a certain particular .so library and even if found another in the regular library path, that at least ensures those symbols are resolved and available for the application (maybe increasing the chances for segmentation faults or the like memory errors). I've seen LD_PRELOAD being used for overriding some application behavior (again, with NWN and some addons for Linux, like the nwuser library which sets the basic infrastructure for the game to save its data onto the user's /home directory rather than the current game directory).
                          Each has it's own issues. LD_LIBRARY_PATH forces the system to look up the libraries in the specified path first when doing a lookup and then applies the ld.so.cache lookups if it can't find what it's looking for the LD_LIBRARY_PATH. LD_PRELOAD explicitly preloads the specified .so files before any linkage or execution is attempted on a binary. Neither is really good from the standpoint of a regular binary- you typically use them to debug or to sidestep a problem with a binary and the current runtimes you have.

                          For some background:

                          http://xahlee.org/UnixResource_dir/_/ldpath.html
                          http://prefetch.net/articles/linkers.badldlibrary.html
                          http://blogs.sun.com/rie/date/20040710
                          http://www.kernelthread.com/publications/umischiefs/ (For the last one search for LD_PRELOAD on the page...)

                          LGP provides LD_PRELOAD/LD_LIBRARY_PATH dynamic linkable binaries to provide compliance with the LGPL licensing terms and to provide a way for people to sidestep very specific issues when they might arise with a given system.
                          Last edited by Svartalf; 09-18-2007, 08:46 PM.

                          Comment


                          • #43
                            The main problem with commercial applications (such as games) in Linux is the heterogeneity of the system from distribution to distribution, particularly in those with long release cycles, as they tend to have older libraries to linger for a much longer time, not only that, but also the many versions at any one time of GCC libraries. As such it would be best for a commercial application to pretty much package the libraries it was linked against and force their use rather than the system-wide libraries, or statically link against those (having the side effect of fattening the binary). Those are the main issues, from what I've been able to observe:
                            1. GlibC version.
                            2. GCC version, libs and version which the system libs were built with.
                            3. C++ runtime libraries version.

                            That's when LD_LIBRARY_PATH and LD_PRELOAD are most useful.

                            Judging from some of the sites you cited, it would seem as if it would more beneficial if the application programmers at build time, used specific link paths so that the binary would "look" for those libs at run time, regardless of system configuration and as such they could rely more on their own "local" ./lib path [1]. So if I understand this correctly, they could simply build having int mind their own application's directory structure and ship the libraries they may need without relying on LD_LIBRARY_PATH or LD_PRELOAD at all (if I read correctly this should be done with the ld -R flag at link time). However most cases I've seen of LD_LIBRARY_PATH being set are in wrapper mode (the lesser evil).

                            Most of the references you provided, however are for Solaris, so I have to wonder if GCC's ld in Linux does support the -R flag [2].

                            The LD_PRELOAD reference is quite a nice read! Simply due to its function, LD_PRELOAD could be very dangerous, depending on its use.

                            Thanks for the great references!

                            Comment


                            • #44
                              Originally posted by Thetargos View Post
                              The main problem with commercial applications (such as games) in Linux is the heterogeneity of the system from distribution to distribution, particularly in those with long release cycles, as they tend to have older libraries to linger for a much longer time, not only that, but also the many versions at any one time of GCC libraries. As such it would be best for a commercial application to pretty much package the libraries it was linked against and force their use rather than the system-wide libraries, or statically link against those (having the side effect of fattening the binary). Those are the main issues, from what I've been able to observe:
                              1. GlibC version.
                              2. GCC version, libs and version which the system libs were built with.
                              3. C++ runtime libraries version.
                              In the case of the first two, Autobuild from the Autopackage project happens to resolve this so it will gracefully handle a LARGE range of runtimes because of the nature of how glibc accomplishes ABI versioning support (incl. an odd way of handling backwards compatibility...) The C++ runtime libs issue's a mess- Autobuild will resolve a goodly portion of these, but I've not used it as much as just simply statically linking that one with myself (it will still dlopen the glibc you specify with the ABI, etc. through Autobuild and as long as you're not flipping around stuff via C++, you end up being fine.

                              That's when LD_LIBRARY_PATH and LD_PRELOAD are most useful.
                              Indeed. It's just that they have severe security and stability concerns and shouldn't be used except in the case of a problem with your app just not working right. What the vendors are doing when they use this out of the gate first is showing that they don't understand how things work as well as they ought to. That's not to say we're not happy with them making the stuff, but...

                              Judging from some of the sites you cited, it would seem as if it would more beneficial if the application programmers at build time, used specific link paths so that the binary would "look" for those libs at run time, regardless of system configuration and as such they could rely more on their own "local" ./lib path [1]. So if I understand this correctly, they could simply build having int mind their own application's directory structure and ship the libraries they may need without relying on LD_LIBRARY_PATH or LD_PRELOAD at all (if I read correctly this should be done with the ld -R flag at link time). However most cases I've seen of LD_LIBRARY_PATH being set are in wrapper mode (the lesser evil).
                              Yep. Unfortunately we don't HAVE the -R flag available to us, to the best of my knowlege, and it's still an issue.

                              The LD_PRELOAD reference is quite a nice read! Simply due to its function, LD_PRELOAD could be very dangerous, depending on its use.

                              Thanks for the great references!
                              You're very much welcome. It always helps to know and understand why something's much less than desirable if it can be avoided.

                              Comment


                              • #45
                                Not having -R to ld or the $ORIGIN variable sure can be a problem in Linux. I wonder if there is work being done to implement those?

                                Comment

                                Working...
                                X