Announcement

Collapse
No announcement yet.

LGP Has A New Linux Game Installer

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

  • LGP Has A New Linux Game Installer

    Phoronix: LGP Has A New Linux Game Installer

    Linux Game Publishing, the company behind porting such games to Linux as Cold War and X2: The Threat, has prepared a new Linux GUI installer for its forthcoming titles. While this new installer doesn't feature any overwhelming additions, it has been written finally to use GTK2 and other new functionality for this setup utility.

    http://www.phoronix.com/vr.php?view=11899

  • #2
    Just great...

    Oh great, exactly what I want, the Windows style of installing software to gain mindshare in Linux.

    One of the major gripes I have with Windows is software install/deinstall is so haphazard with umpteen different installers and deinstallers that don't always register with add/remove programs correctly. Under most linux distributions, much better package managed approaches are available to leverage. The significant downside, of course, being you cannot install/deinstall without root privilege, and no package manager makes concessions such that is easily accomodated (you can do so, but it becomes more complex than a desktop user should be expected to deal with), and that remains one reason for the installer I suppose.

    Without knowing more about the company, I hope they at least provide debs and rpms as well as this installer. I don't want to see one of my favorite aspects of Linux distributions not be leveraged for all my software. Making a yum and apt repository available would be even smoother for patches.

    Comment


    • #3
      Originally posted by makoto42 View Post
      One of the major gripes I have with Windows is software install/deinstall is so haphazard with umpteen different installers and deinstallers that don't always register with add/remove programs correctly. Under most linux distributions, much better package managed approaches are available to leverage. The significant downside, of course, being you cannot install/deinstall without root privilege, and no package manager makes concessions such that is easily accomodated (you can do so, but it becomes more complex than a desktop user should be expected to deal with), and that remains one reason for the installer I suppose.
      You're probably an end user. What you DON'T know is that each distro, RPM based or DEB based happens to be a minefield for providing a "universal" package. Each one has slightly differing rules for where things go. And this doesn't even get into Gentoo or similar distributions which doesn't HAVE a packaging system like RPM or DEB but pull from source trees and builds everything.

      You don't see the "nightmare" because you typically go with Red Hat prepared RPMs or SuSE prepared RPMs. DEBs tend to be a wee bit cleaner, but it's NOT assured that you're going to get consistent results, even if they're not "part of the package system". The installer, typically installs the game to your home directory unless you override that by installing as root, where it drops it in /usr/local usually. You want games installed in your home directory unless you've got a multi-user system anyhow.

      Without knowing more about the company, I hope they at least provide debs and rpms as well as this installer. I don't want to see one of my favorite aspects of Linux distributions not be leveraged for all my software. Making a yum and apt repository available would be even smoother for patches.
      You know what? Get them to be consistent amongst themselves and you might see that. We're not participants because there's no easy way for someone to DO that unless you're part of the source tree for the distribution or you're making a Red Hat, SuSE, Ubuntu, Debian, etc. package. So...either we snub a bunch of people, or we make an app installer that's not part of the packaging system. Take your pick.
      Last edited by Svartalf; 02-26-2008, 09:46 AM.

      Comment


      • #4
        Originally posted by makoto42 View Post
        One of the major gripes I have with Windows is software install/deinstall is so haphazard with umpteen different installers and deinstallers that don't always register with add/remove programs correctly. Under most linux distributions, much better package managed approaches are available to leverage.
        Same here, but this installer aims for proprietary games and I wouldn't mind it messing around in my home directory, while the system stays clean.

        Comment


        • #5
          hmm ROTFL. Long, LONG, LOONG time ago (when orginal loki installer was updated to gkt2) I wrote to LGP. I sugested to change installer to gtk2. The answer have been very funny... somethink like this "not all people have gtk2.. bla bla bla. We are not planing update of installer" yeaaah more people have gtk1 -_-".
          Ow, and this new installer looks like normal loki installer on gtk2 :P

          But after all, its nice to (finally) see installer in gtk2

          Comment


          • #6
            So it is interesting that LGP didn't use the Mojo installer. Does anyone have any info on why LGP chose not to use the Mojo Installer and instead update their old installer seperately?

            Also, for some reason I thought both installers were from the same codebase at one point... I guess I thought this was the case since both installers seemed so similar to me.

            Comment


            • #7
              Originally posted by Svartalf View Post
              You're probably an end user. What you DON'T know is that each distro, RPM based or DEB based happens to be a minefield for providing a "universal" package. Each one has slightly differing rules for where things go. And this doesn't even get into Gentoo or similar distributions which doesn't HAVE a packaging system like RPM or DEB but pull from source trees and builds everything.

              You don't see the "nightmare" because you typically go with Red Hat prepared RPMs or SuSE prepared RPMs. DEBs tend to be a wee bit cleaner, but it's NOT assured that you're going to get consistent results, even if they're not "part of the package system". The installer, typically installs the game to your home directory unless you override that by installing as root, where it drops it in /usr/local usually. You want games installed in your home directory unless you've got a multi-user system anyhow.



              You know what? Get them to be consistent amongst themselves and you might see that. We're not participants because there's no easy way for someone to DO that unless you're part of the source tree for the distribution or you're making a Red Hat, SuSE, Ubuntu, Debian, etc. package. So...either we snub a bunch of people, or we make an app installer that's not part of the packaging system. Take your pick.
              I'm a developer/packager supporting Fedora, RHEL, SuSE, and Ubuntu. I'm all too aware packaging can be a nightmare, and the systems don't make it easy to make one package to rule them all, but your first few words 'you're probably an end-user' are precisely why I go through the pain and endure the nightmare, for a sane user experience. The problem with making your solution equally palatable to Ubuntu, Fedora, SuSE, Gentoo, Linux from scratch, Slackware, etc is that in the end you make something equally unpalatable to them all. As a packager I pick and chose my battles so that the largest portion of my userbase gets a great experience, while others deal with the lowest common denominator that many would have only provided in the first place. It's the singular thing I adore about AMD's drivers, the packaging (and dkms) straight from the vendor, while the nVidia is a mild annoyance to maintain. Adobe one ups AMD on a Fedora system with a yum repository, a great thing for applications to hook patches into.

              Another suggestion: have the arbitrarily complicated set of distro-specific packages and your fancy GUI a frontend to install the packages as appropriate. That caters to both crowds, and I can ignore the GUI and those that use the GUI still get the integrated experience.

              Comment


              • #8
                Originally posted by Svartalf View Post
                You're probably an end user. What you DON'T know is that each distro, RPM based or DEB based happens to be a minefield for providing a "universal" package. Each one has slightly differing rules for where things go. And this doesn't even get into Gentoo or similar distributions which doesn't HAVE a packaging system like RPM or DEB but pull from source trees and builds everything.

                You don't see the "nightmare" because you typically go with Red Hat prepared RPMs or SuSE prepared RPMs. DEBs tend to be a wee bit cleaner, but it's NOT assured that you're going to get consistent results, even if they're not "part of the package system". The installer, typically installs the game to your home directory unless you override that by installing as root, where it drops it in /usr/local usually. You want games installed in your home directory unless you've got a multi-user system anyhow.



                You know what? Get them to be consistent amongst themselves and you might see that. We're not participants because there's no easy way for someone to DO that unless you're part of the source tree for the distribution or you're making a Red Hat, SuSE, Ubuntu, Debian, etc. package. So...either we snub a bunch of people, or we make an app installer that's not part of the packaging system. Take your pick.
                I've handled these things first hand and I certainly don't like the packaging nightmare. I find interesting though that LGP didn't go for Mojo. I don't find any fault on LGP on this install issue. It's simply a means to an end.

                Now, I would dread this news if this was the big coup that Svartalf was hyping us all for.

                Comment


                • #9
                  Originally posted by niniendowarrior View Post
                  Now, I would dread this news if this was the big coup that Svartalf was hyping us all for.
                  Not on a bet, it's not. I wouldn't have wasted either my time or any of yours if it was this...

                  Comment


                  • #10
                    Originally posted by joshuapurcell View Post
                    So it is interesting that LGP didn't use the Mojo installer. Does anyone have any info on why LGP chose not to use the Mojo Installer and instead update their old installer seperately?

                    Also, for some reason I thought both installers were from the same codebase at one point... I guess I thought this was the case since both installers seemed so similar to me.
                    Mojo's RADICALLY different in many ways. Better, probably, but it's definitely NOT the same beastie. Nor. do I believe, are they compatible with each other.

                    LGP has an installed title base out there. We'd have to come up with a converter for the uninstall/patch system already in place with the Loki derived LGP installer/patcher system. Not that we couldn't have done this, but I suspect Michael Simms is thinking in terms of the medium term answers here.

                    Comment


                    • #11
                      Originally posted by makoto42 View Post
                      Another suggestion: have the arbitrarily complicated set of distro-specific packages and your fancy GUI a frontend to install the packages as appropriate. That caters to both crowds, and I can ignore the GUI and those that use the GUI still get the integrated experience.
                      Heh... Now you have us making packages for EVERYONE and spending less time on developing ports...

                      It's a nice idea, but in the end, you're not making it easier- you're making it more difficult on the vendors. Not a good idea, if you think about it.

                      The biggest problem that few people realize (even the people MAKING the distributions are on that list of people...) is that the packaging system on their pet distribution (Heh... I've got three so far... Ubuntu, Fedora, and Mandriva..) happens to be tied fairly tightly to that distribution- and that while it all works together nicely from a YUM, URPMI, or APT (or "FOO", for that matter...) repository or off their CD/DVD, once you try to pull in stuff from another distribution or from a non-source derived origin (say, GAMES...), you end up taking a chance on the things not working- or possibly messing the whole thing up badly enough that unless you know what you're doing, you're in for a reinstall.

                      I know, I've done this sort of thing before with Alien in the past. Not pretty.

                      It makes for a LOT more work than it's honestly worth, if you start thinking about it from that perspective- take a chance of fubaring their machine, or drop it in their home directory like we do and prep things THAT way. Which would YOU have?

                      Comment


                      • #12
                        About time guys!

                        As for MojoSetup - sure, technically, it sounds great. One flaw (yes, I do consider it one) - it's terminal-based.

                        Hello, it even doesn't launch a terminal of it's own when you double-click on it. Forcing you to open a terminal, cd, and run it. Argh.

                        I really like the Loki installers, and hope this one is just as good.

                        Comment


                        • #13
                          Maybe you should look at build services like openSUSE has. It's capable of creating packages for multiple distros and architectures in one easy to manage project.

                          The openSUSE Build Service already supports several Linux distributions including openSUSE, Debian, Fedora, Mandriva, SUSE Linux Enterprise, CentOS and Ubuntu with more distro's being added all the time.

                          Comment


                          • #14
                            I think for binary only packages like game it makes sense to have a two path approach:

                            1) Plain installer:
                            Make the installer file executable, start the installer (doubleclick in the ide, ./installer.sh, whatever), have it installed where you are allowed to write with the normal users privileges. This is an approach which will work nicely for all who do not care about the distributions.

                            2) Option to extract files in no-GUI mode
                            Allow the package/installation be somehow extracted in a no-GUI mode. This leads to allowing package managers to do this extraction in a temp folder and just copy the files over to the distribution specific places. This does of course require ways to tell the binary where the games datafiles are located. Each distribution could then write an own tiny shellscript, which is put in the normal $PATH and just calls the normal binary with the params needed.

                            I think with such an approach the games vendor (or company porting) "just" has to follow the normal path setups that every program should adhere to anyway, plus provide a no-GUI mode in the installer, that basically performs an installation in a temp folder whichs content can afterwards be copied around. I think basically every package manager does allow a procedure like this. Of course the distributions do have to provide their packager files which handle those copying, but that is a job for the distributions maintainer.

                            Comment


                            • #15
                              I don't know this one, but usally every .run file is made with makeself.sh. The nvidia installer is derived from an older version (1.6.0) and the ati installer from a newer one (2.1.3). I patched the ati installer to support lzma - I could do that for any newer makeself installer and all have an option to extract only (-x).

                              Hint: you find the makeself.sh used by nvidia when use -x at usr/bin/makeself.sh - this is used when you use the --add-this-kernel or --apply-patch options...
                              Last edited by Kano; 02-27-2008, 07:04 AM.

                              Comment

                              Working...
                              X