Announcement

Collapse
No announcement yet.

Ryan Gordon Is Fed Up, FatELF Is Likely Dead

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

  • #31
    Good riddance. We shouldn't be copying Apple's stupider ideas.

    Comment


    • #32
      Alan Cox gave a lot good reasons why fatelf is not needed in any way on lkml.

      Comment


      • #33
        I, for some reason, liked the idea of FatELF, especially for the main reason of multi-platform-binaries for commercial games. Well, I'm not sure if this would have addressed some core problems of building binaries for different platforms, but at least it could have addressed the way how they are distributed.

        I also don't see the distribution package-managers as a viable option for installing big commercial games for various reasons. Maybe that's just me, but as I'm already having about 50+ GB of games installed on my home directory, I don't really want all of them to be installed through the package manager and therefor be installed somewhere in my system where I don't really know where it is (for the main reason of space, of course).

        Well I'm sure many will disagree with me here since I'm talking about commercial software, though I see commercializing games as a viable option for game studios, even on Linux and FatELF could have helped them with easier package distribution.

        Comment


        • #34
          so what? if you put the crap in your $HOME you are certainly able to download or copy the right binary package.

          For everybody else there is a package manager. And distros with a good multilib setup don't even care if a bianry is 32 or 64bit.

          FatELF is a non-solution in search of a problem.

          Comment


          • #35
            Originally posted by deanjo View Post
            Not dodging the questions at all, had old games such as loki games used such a approach I would still be able to use those games for example in a modern distro. Right now you try to run some of those old games and they *cough* *puke* and fart trying to find matching libs. In a "universal binary" approach this wouldn't be the case. Even in opensource projects such as Warsow this is a issue for example where it specifically looks for libcurl3 where as my distro has long gone and replaced that for libcurl4 (and doesn't even offer libcurl3 anymore). So what do you do you go and gripe to the game devs saying "hey my distro uses xyz lib though" to which the reply all to often today is "well it works on ubuntu". Then there is the issue as well that each distro's location of libs can vary some dump it in various places like /lib or /lib32 or /lib64 etc. BTW, Apple's universal libraries also handle more then just 2 arch, 4 by default PPC32 PPC64, x86 and x86-64. Your right, it can lead to a very big binary size but in reality how many ET:QW games are going to only need a recompile to play it on a arm arch? This is where common sense comes into play, but nice try at the "worst case" scenario play as unlikely as it is to ever come into reality.

            Ryan is just trying to make a solution that would allow commercial developers to develop for linux without having to worry about each distro's "nuance" in order to get their product to run on each persons flavor of linux. This is a sore point that does hold linux back from being mainstream (as well, like it or not the lack of commercial apps).
            a universal binary wouldn't help you in any way.

            Stop that right there. You don't even know what you are talking about.

            Btw, CivCTP still works:
            just use the static binary
            turn of HEAP RANDOMIZATION

            and it runs. Without multilib, fatelf or whatever.

            And Mac - well, what was the last version of MacOSX for PPC? PPC and PPC64 aren't that diffenrent and fatelf does not save you bacon when it comes to libs.

            So. No. FATELF is a stupid idea. Solving no problems. Only creating new ones.

            Comment


            • #36
              Who else here is sick of the constant UT3 remarks in every single icculus article?
              i, for one, am sick of article full of self-referring links, that makes the text all green.

              who cares about ut3 linux at this point, anyway?

              Comment


              • #37
                Originally posted by deanjo View Post
                Not dodging the questions at all, had old games such as loki games used such a approach I would still be able to use those games for example in a modern distro. Right now you try to run some of those old games and they *cough* *puke* and fart trying to find matching libs. In a "universal binary" approach this wouldn't be the case. Even in opensource projects such as Warsow this is a issue for example where it specifically looks for libcurl3 where as my distro has long gone and replaced that for libcurl4 (and doesn't even offer libcurl3 anymore). So what do you do you go and gripe to the game devs saying "hey my distro uses xyz lib though" to which the reply all to often today is "well it works on ubuntu". Then there is the issue as well that each distro's location of libs can vary some dump it in various places like /lib or /lib32 or /lib64 etc. BTW, Apple's universal libraries also handle more then just 2 arch, 4 by default PPC32 PPC64, x86 and x86-64. Your right, it can lead to a very big binary size but in reality how many ET:QW games are going to only need a recompile to play it on a arm arch? This is where common sense comes into play, but nice try at the "worst case" scenario play as unlikely as it is to ever come into reality.

                Ryan is just trying to make a solution that would allow commercial developers to develop for linux without having to worry about each distro's "nuance" in order to get their product to run on each persons flavor of linux. This is a sore point that does hold linux back from being mainstream (as well, like it or not the lack of commercial apps).
                Ok, so it sounds like you are less concerned with the ability to have a binary run on multiple architectures and more impressed by the ability for it to embed libraries directly into it? I wasn't aware that it could do that, and I'm still not sure why that's such an awesome thing - couldn't Warsaw just stick libcurl3 next to the executable and load the locally provided copy rather than going to the system lib? It seems like it's exactly what you're looking for anyway, just seperated into a 2nd file, or am I missing your point?

                BTW, there was another technology around a year or two ago that did something similar, without requiring massive changes to ELF. I think it mounted the file as a filesystem and everything that was needed to run was present there and automatically handled for you, so that no system libs were required. I can't remember what it was called, though.

                I understand what Ryan is trying to do here, it just seems like a really fundamentally large change to the system in exchange for supporting a group that isn't exactly a priority on linux, or very large right now. Not making judgements myself there, I'm just saying the problems he is having selling this to the rest of the projects it would affect were pretty forseeable. And it seems to me like there are less intrusive ways to solve the issues that his system is meant to, if he had thought about the best way to do this within Linux rather than starting with a solution from Apple and trying to port it over to Linux.
                Last edited by smitty3268; 11-04-2009, 04:40 AM.

                Comment


                • #38
                  Originally posted by energyman
                  so what? if you put the crap in your $HOME you are certainly able to download or copy the right binary package.

                  For everybody else there is a package manager. And distros with a good multilib setup don't even care if a bianry is 32 or 64bit.

                  FatELF is a non-solution in search of a problem.
                  Well that's true, no big deal for me. I more thought about devs of Mac games hesitate to make a Linux port of there games, because of to the lack of multi-lib binaries. But well, as I see that you don't care at all about this "crap", lets end this here. I may also just be wrong if I thought this could have helped them in any way, as I'm just a humble user and not a coder at all.

                  Originally posted by yoshi314 View Post
                  i, for one, am sick of article full of self-referring links, that makes the text all green.

                  who cares about ut3 linux at this point, anyway?
                  Put me on the list of "sick of article full of self-referring links" and I also don't care about UT3 anymore.

                  Comment


                  • #39
                    Originally posted by deanjo View Post
                    Then there is the issue as well that each distro's location of libs can vary some dump it in various places like /lib or /lib32 or /lib64 etc. BTW, Apple's universal libraries also handle more then just 2 arch, 4 by default PPC32 PPC64, x86 and x86-64. Your right, it can lead to a very big binary size but in reality how many ET:QW games are going to only need a recompile to play it on a arm arch? This is where common sense comes into play, but nice try at the "worst case" scenario play as unlikely as it is to ever come into reality.

                    Ryan is just trying to make a solution that would allow commercial developers to develop for linux without having to worry about each distro's "nuance" in order to get their product to run on each persons flavor of linux. This is a sore point that does hold linux back from being mainstream (as well, like it or not the lack of commercial apps).
                    Okay, a few problems with your approach here:

                    - Why do you even need to be able to install the same package on many different archs?
                    If you choose a x64-arch you can still install x86-packages just fine, and with x86 you can't work with x64 either way. If you say "using x86 on x64 causes a shitload of deps", well big surprise, FatELF still has those deps and duplicate libs, just packaged differently and without providing bugfixes and security patches to it.
                    If have an exotic or mobile arch like say, Arm or PPC or something you will most like need a customized distro/kernel either way, and thus most of your programms will only be specialized/ported either way. FatELF doesn't make stuff magically run on your Freerunner.

                    - Which programs benefit from FatELF?
                    Most stuff won't have any advantage with FatELF - basically all open-source projects can be easily installed AND updated from the distro repository, and if not they most likely will provide either debs or rpms, which can be converted if nothing to ditro-level is included. OSS that doesn't include packages will likely not give a f*** about FatELF!
                    Games... well guess what, most closed-source games don't bother with other archs than x86 at all, and have real problems with space already. They will build for x64 the same moment THEY NEED TO!, which means when they start needing more than 4Gb-Ram.
                    After that there is only one way FatELF could do what you want it to: bundling all needed libs, compilers,runtimes, and whatnot with the ELF and installing it.

                    Guess where that ends:
                    - you will have at least 4 version of GCC and it's libs installed
                    - none of the packages included will have security patches and none of the companies will bother maintaining half the Linux-Desktop
                    - this won't help you the slightest if the kernel-Api breaks or FatELF releases new versions

                    Comment


                    • #40
                      Originally posted by M1AU View Post
                      Well that's true, no big deal for me. I more thought about devs of Mac games hesitate to make a Linux port of there games, because of to the lack of multi-lib binaries.
                      Originally posted by M1AU View Post
                      not a coder at all
                      Originally posted by M1AU View Post
                      not a coder
                      The problem with Mac games not being ported are many:
                      - Really bad drivers and driver support for graphics
                      - Compilers not having stable APIs, making it fun to port everytime gcc releases something new
                      - different distros behaving differently
                      - No established content architectures like steam
                      - Wine already providing "fair enough"-support for some stuff
                      - too little commercial potential(Yes, you CAN argue about that one)
                      - and so on

                      FatELFs are Multi-Arch-Binaries, thus not solving anything, Multi-Lib-Binaries have their own problems, for example: have fun maintainig this.
                      Windows sidesteps this with having multiple DLLs of fucking everything, but thats referred to as "DDL-hell" for a reason. For examlple: whatever happens if a security update or a third party changes the dll?

                      Comment


                      • #41
                        Originally posted by energyman View Post
                        a universal binary wouldn't help you in any way.

                        Stop that right there. You don't even know what you are talking about.

                        Btw, CivCTP still works:
                        just use the static binary
                        turn of HEAP RANDOMIZATION

                        and it runs. Without multilib, fatelf or whatever.

                        And Mac - well, what was the last version of MacOSX for PPC? PPC and PPC64 aren't that diffenrent and fatelf does not save you bacon when it comes to libs.

                        So. No. FATELF is a stupid idea. Solving no problems. Only creating new ones.
                        Good for CivCTP, unfortunately, F.A.K.K, SoF, and another that I have somewhere don't. Same can be said with NWN. Sure you can get them running after fucking around with the libs and such.

                        Comment


                        • #42
                          Originally posted by fabiank22 View Post
                          The problem with Mac games not being ported are many:
                          - Really bad drivers and driver support for graphics
                          - Compilers not having stable APIs, making it fun to port everytime gcc releases something new
                          - different distros behaving differently
                          - No established content architectures like steam
                          - Wine already providing "fair enough"-support for some stuff
                          - too little commercial potential(Yes, you CAN argue about that one)
                          - and so on

                          FatELFs are Multi-Arch-Binaries, thus not solving anything, Multi-Lib-Binaries have their own problems, for example: have fun maintainig this.
                          Windows sidesteps this with having multiple DLLs of fucking everything, but thats referred to as "DDL-hell" for a reason. For examlple: whatever happens if a security update or a third party changes the dll?
                          Thanks for pointing that out.

                          Comment


                          • #43
                            Originally posted by fabiank22 View Post
                            Okay, a few problems with your approach here:

                            - Why do you even need to be able to install the same package on many different archs?
                            If you choose a x64-arch you can still install x86-packages just fine, and with x86 you can't work with x64 either way. If you say "using x86 on x64 causes a shitload of deps", well big surprise, FatELF still has those deps and duplicate libs, just packaged differently and without providing bugfixes and security patches to it.
                            Sure and your friendly distro packager makes sure that most of those are so intertwined with dependencies on other NOT NEEDED libs that it slaps a bunch more code that is not needed. At least with a "Universal Binary" I can get rid of the whole item without worrying about breaking other apps and not having no longer needed libs on my system.

                            If have an exotic or mobile arch like say, Arm or PPC or something you will most like need a customized distro/kernel either way, and thus most of your programms will only be specialized/ported either way. FatELF doesn't make stuff magically run on your Freerunner.
                            I pointed that out. You have to keep the target in mind. Nobody in their right mind is going to package a application for something that simply does not have the resources to run said application.

                            - Which programs benefit from FatELF?
                            Most stuff won't have any advantage with FatELF - basically all open-source projects can be easily installed AND updated from the distro repository, and if not they most likely will provide either debs or rpms, which can be converted if nothing to ditro-level is included. OSS that doesn't include packages will likely not give a f*** about FatELF!
                            Games... well guess what, most closed-source games don't bother with other archs than x86 at all, and have real problems with space already. They will build for x64 the same moment THEY NEED TO!, which means when they start needing more than 4Gb-Ram.
                            After that there is only one way FatELF could do what you want it to: bundling all needed libs, compilers,runtimes, and whatnot with the ELF and installing it.
                            Actually the later commercial games that have come out have been offered in 64-bit flavor as well. Compilers be bundled in a FatELF wouldn't be needed as the apps are already compiled.

                            Guess where that ends:
                            - you will have at least 4 version of GCC and it's libs installed
                            - none of the packages included will have security patches and none of the companies will bother maintaining half the Linux-Desktop
                            - this won't help you the slightest if the kernel-Api breaks or FatELF releases new versions
                            All of this applies as it is already found in it's current state so I really fail to see your point here.

                            Ultimately all that Ryan was looking for was some input for working together to a common goal but instead he got and I quote:

                            I imagined
                            people would discuss the merits and flaws of the idea and we'd work towards
                            an agreeable solution that improves Linux for everyone. It sure seemed to
                            be going that way at first. Ultimately, I got hit over the head with package
                            management, the bane of third-party development, as a panacea for everything.
                            Last edited by deanjo; 11-04-2009, 06:05 AM.

                            Comment


                            • #44
                              Originally posted by deanjo View Post
                              Ultimately all that Ryan was looking for was some input for working together to a common goal but instead he got and I quote:
                              Like some people mentioned before it seems he looked from the bad side and bad ideas shouldn't affect Linux, just because someone wants to 'help' in his opinion. Afaik packagekit is a common goal.
                              Last edited by kraftman; 11-04-2009, 07:11 AM.

                              Comment


                              • #45
                                Originally posted by kraftman View Post
                                Like some people mentioned before it seems he looked from the bad side and bad ideas shouldn't affect Linux, just because someone wants to 'help' in his opinion. Afaik packagekit is a common goal.
                                Packagekit still relies on every distro to have all dependencies available that are needed for the application to run and packaged in a manner that is verified working with that application. It does not help at all for example in situations where a dependent library is not available by the distro or where the distro may have upgraded to a newer version that may not work with the application. Packagekit has the exact same flaws as distro specific packaging has where you are still at your distro's packagers mercy to keep it working with the various releases. You still need at least 1 maintainer of that package for each distro.

                                Comment

                                Working...
                                X