Announcement

Collapse
No announcement yet.

Frayed Knights for Linux - a maybe

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

  • #21
    Originally posted by Thetargos View Post
    Which is what most commercial Linux games do, anyway, just see NWN's 'nwn' launcher script, or UT2K*, or UT99, etc.
    Which is also why people now have to go start hacking the startup scripts to get the games to run on newer distro's. NWN for example is broke on most modern distro's to prevent it using the SDL libraries that shipped with the game. Let it use the systems libraries and all is OK again.

    Comment


    • #22
      Originally posted by deanjo View Post
      Which is also why people now have to go start hacking the startup scripts to get the games to run on newer distro's. NWN for example is broke on most modern distro's to prevent it using the SDL libraries that shipped with the game. Let it use the systems libraries and all is OK again.
      Not necessarily true. I had a case recently where the version of SDL shipping with Dark Horizons:Lore Invasion wouldn't run for some distros, the system provided one wouldn't run either. The solution was for me to package the SDL that I was using in Kubuntu 7.10 & for people of 4 distros I know of to use the shell script to correct the issue.

      Comment


      • #23
        Originally posted by SlackerTD View Post
        Not necessarily true. I had a case recently where the version of SDL shipping with Dark Horizons:Lore Invasion wouldn't run for some distros, the system provided one wouldn't run either. The solution was for me to package the SDL that I was using in Kubuntu 7.10 & for people of 4 distros I know of to use the shell script to correct the issue.
        I didn't say it was the only solution, I was just using what had to be done for NWN to work on newer distros as an example.

        Comment


        • #24
          Originally posted by deanjo View Post
          This is where LSB should be pushed and embraced and refined. ALSA is currently being evaluated for inclusion in the next version of LSB.
          http://refspecs.linux-foundation.org...Use/book1.html
          I dont agree with LSB at all... Not even a little bit..

          The problem with LSB is that it literally prevents innovation in every possible way. One way of going things may not be the best way. So if I develop a different way of doing that same thing, it may not be compatible, but eventually it may well replace the old way... This is what is commonly known as progress. Better methods replacing deprecated methods. LSB completely eliminates that possibility... Innovation dies with LSB...

          Just look at the package manager that LSB requires and then you'll knwo exactly what I'm talking about.

          Comment


          • #25
            Originally posted by duby229 View Post
            I dont agree with LSB at all... Not even a little bit..

            The problem with LSB is that it literally prevents innovation in every possible way. One way of going things may not be the best way. So if I develop a different way of doing that same thing, it may not be compatible, but eventually it may well replace the old way... This is what is commonly known as progress. Better methods replacing deprecated methods. LSB completely eliminates that possibility... Innovation dies with LSB...

            Just look at the package manager that LSB requires and then you'll knwo exactly what I'm talking about.
            The LSB does not limit innovation at all, but ensures that a common solution is available. I assume your griping about RPM being package standard. LSB can still be adhered too with debs when alien is used.

            Again, if there is a better solution to an issue the lsb can be changed and amended, thus why I said it has to be refined. LSB should be viewed as a common set of required tools to maintain cross compatibility.
            Last edited by deanjo; 28 May 2008, 10:18 AM.

            Comment


            • #26
              But then you have the problem that if LSB can be changed at will (which it cant be), then what is the point? In that case it has no value at all becouse it serves no purpose.

              Additionally your assuming that all folks will be using RPM, or Apt. The fact is that is not at all the case. Your also assuming that all people will be running xorg. Your assuming that all people will be running alsa. Your assuming that all people will be running apache. Your assuming that all people will be running udev. Ands many,many,many,many more assumptions that all prove to be simply false.

              I'm sorry but it just doesn't work that way. If you change one of these LSB required components then you will break compatibility. But if I'm running a server I dont need xorg installed. I may choose to use a modern version of OSS instead of the deprecated version that is in the kernel. I may well opt to use a framebuffer device for the display if I am using my system as a PVR. And there are many,many,many,many more examples then just these where LSB simply does not work.

              I'd even go so far as to say that LSB will only work for less the 0.000001% of the entire linux community, and even in that extremely rare case it will be entirely deprecated and unsupported in less then three days of use.

              The fact of the matter is that LSB does --not-- ensure compatibility. It actually breaks compatibility in the simple fact that LSB makes it entirely impossible for most folks to do what they want to do. Not to mention that it makes replacing deprecated components impossible.

              The moment you replace RPM you've broken compatibility. The moment you've replaced glibc, or udev, or hal, or binutils, or xorg, or alsa you have broken compatibility. In order to maintain compatibility you will permanently be stuck with the packages and versions of those packages that you've chosen. This is exactly what LSB does, and it is exactly what is wrong with it...

              Comment


              • #27
                Originally posted by deanjo View Post
                I didn't say it was the only solution, I was just using what had to be done for NWN to work on newer distros as an example.
                For example, other vendors provide dynamic link versions of their titles for dealing with the odd problem or an ABI breakage- but provide statically linked binaries (yes, it's big, but then the result ends up being consistent across a HUGE range of distributions and versions of the same...) and only get broken when something dramatic happens in the glibc ABI or the Linux kernel hooks. Loki's stuff ran until the ABI got changed sufficiently enough to break them all to hell.

                Comment


                • #28
                  Originally posted by deanjo View Post
                  The LSB does not limit innovation at all, but ensures that a common solution is available. I assume your griping about RPM being package standard. LSB can still be adhered too with debs when alien is used.

                  Again, if there is a better solution to an issue the lsb can be changed and amended, thus why I said it has to be refined. LSB should be viewed as a common set of required tools to maintain cross compatibility.
                  But Alien's a band-aid on the problem. You see, the standardization was a good idea- LSB is just poor execution that only the RPM based distributions can actually follow. In fact, I think SuSE and Red Hat are the only ones that slavishly follow the thing, being that they're the main ones for coming up with it. Debian can't really follow it that closely because it's really, really Red Hat centric if you read it closely. Worse, RPM, internally does all kinds of goofy-loopy things. Which version do you want to support and realize that the packaging tools vary on macros, etc. so you're not going to get consistent results there either.

                  LSB's a poor execution to a nice idea. Don't know if you CAN get that execution any better though without ditching the notion of packaging being controlled by the spec. You should specify ABI's and API's provided and a certain specific range for this version of the base standard. Until you get to that stage, it's just not going to work. Most of the problems with binaries, etc. is because we can't keep consistent across distros with ABIs (we didn't have a consistent C++ ABI until recently, for example...) and the lot. Not about where binaries should be put, not about directory structures, and not about what packaging manager you're using. LSB specifies all of it. You might as well be using Red Hat at that point.

                  Comment

                  Working...
                  X