Announcement

Collapse
No announcement yet.

Ryan Gordon Brings Universal Binaries To Linux

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

  • #11
    This could be very useful for commercial binaries, ie games and less confusing for the non experts. Ofcourse MacosX has an easier job since it supports just 2 archs.

    Comment


    • #12
      Originally posted by Remco View Post
      How often do you install a plain binary for Linux apps? The correct way to distribute software is by non-executable installer packages. Those kinds of packages can provide any number of architectures in one single file. Or, if you don't like that bloat, discover the user's architecture from browser information and then offer the correct architecture-specific package by default.
      Not that often, but that's not the point. The point is it does happen (games for instance), and you can't reliably discover the architecture via the browser. Sure, the most currently common browsers do provide it, but some (for instance Konqueror) don't, and what do you do then? Say "Hey! I don't know what CPU architecture you're running. It could be ARM, PowerPC, x86, x86_64 etc. Please download the appropriate version."? I don't think that's working too well.

      And what do you mean by "The correct way to distribute software is by non-executable installer packages."? Do you mean the package manager? If so, you're only moving the problem to another area ("Which package manager does the user use?").

      Comment


      • #13
        Originally posted by RealNC View Post
        Bloated crap. No thanks. I hope this project fails.
        +1

        PPC? Thanks, I don't use it and I probably never will.

        Comment


        • #14
          Originally posted by Ex-Cyber View Post
          I don't see any reason to arbitrarily limit the spec to only two architectures, particularly considering the possibilities of ARM-based netbooks. Arch support for a given binary is entirely at the discretion of the distributor in any case.
          What I meant was that the software developer/packager should be able to choose which arches to compile into your FatELF binary. If you only want to support x86/amd64 then you can do that. Or you could throw in PPC or sparc if you want.
          Last edited by pvtcupcakes; 22 October 2009, 11:58 AM.

          Comment


          • #15
            Originally posted by kraftman View Post
            +1

            PPC? Thanks, I don't use it and I probably never will.
            Who cares for PPC except from few old-fashion Apple users? This binary format can be useful for binaries that support x86, x86_64 and maybe future arm platforms since I believe they will be in handy in the near future if Android succeeds finally

            Comment


            • #16
              Commercial Stuff

              Originally posted by Remco View Post
              How often do you install a plain binary for Linux apps? The correct way to distribute software is by non-executable installer packages. Those kinds of packages can provide any number of architectures in one single file. Or, if you don't like that bloat, discover the user's architecture from browser information and then offer the correct architecture-specific package by default.
              This is a very good idea for commercial software that doesn't necessarily want to play nice with .debs or rpm's or whatever. For instance, how about quakelive, the old loki games (I know the company's dead), world of goo?

              A little bloat there is totally worth it if it increases probability that something just works.

              I'd much rather have a bloated fatELF 64-bit native world of goo than just a 32-bit one plus all the extra libraries and incompatibilities I have to wade through to get it to work on a 64-bit system.

              I don't think everything should use this, but some things definitely should as it would lower support costs for the developers, thereby encouraging them to spend more time actually making cool stuff. It's dumb to expect everyone to buy into your distro's package management philosophy.

              Comment


              • #17
                This sounds like an awesome idea. If it can happily resolve problems with kernel mismatch, dynamic linking, API/ABI and architecture differences... it may be a win for game developers wishing to support Linux and other *nix, maybe even macOS...


                It obviously won`t fit the FOSS proposes and the way we manage package toda

                Comment


                • #18
                  Originally posted by AHSauge View Post
                  Not that often, but that's not the point. The point is it does happen (games for instance), and you can't reliably discover the architecture via the browser. Sure, the most currently common browsers do provide it, but some (for instance Konqueror) don't, and what do you do then? Say "Hey! I don't know what CPU architecture you're running. It could be ARM, PowerPC, x86, x86_64 etc. Please download the appropriate version."? I don't think that's working too well.
                  I consider that a bug. Something similar was discovered and reported (and fixed) when the WineHQ website streamlined their download page to point to the right distribution package by default. Konqueror on Ubuntu didn't report Ubuntu. Now it does. Though this streamlining doesn't appear to be in use yet on WineHQ.
                  And what do you mean by "The correct way to distribute software is by non-executable installer packages."? Do you mean the package manager? If so, you're only moving the problem to another area ("Which package manager does the user use?").
                  Non-executable packages are not the solution to this problem, but executable packages are a problem. They are impossible to secure, since they can run arbitrary code. A non-executable installer can be regulated through PolicyKit.

                  So executable installers are not desirable. Then this solution that packs a lot of architectures in one executable file doesn't solve the problem either.

                  The real solution remains a unified package manager interface. The upcoming PackageAPI solves most of the problem. What remains is a packaging format, installed by a PackageAPI-aware package manager, that every distribution agrees to support.

                  In the mean time, directing the user to the right package automatically works very well.

                  Comment


                  • #19
                    Originally posted by Adriano ML View Post
                    This sounds like an awesome idea. If it can happily resolve problems with kernel mismatch, dynamic linking, API/ABI and architecture differences... it may be a win for game developers wishing to support Linux and other *nix, maybe even macOS...


                    It obviously won`t fit the FOSS proposes and the way we manage package toda
                    Idealism and practical considerations need to be and are always going to be in tension, yes? I'll go play my world of goo and scoff at the iceweasel folks now.

                    I think the prevailing thought in FSF guys minds is that they can force everything to be 'free', but I contend that lots of software won't exist if people can't make money off of it.

                    fatELF is a good thing for people that like to use their computer to do things. If there is something that can offer content management in secure way on a linux system, that would be a good next step, like a 'Steam' type service.

                    Comment


                    • #20
                      I'm not sure how shared library loading is implemented in Linux, but if it maps binary into memory, does that mean we'll get a major increase in memory usage once FatELF goes mainstream?

                      Comment

                      Working...
                      X