Page 11 of 16 FirstFirst ... 910111213 ... LastLast
Results 101 to 110 of 160

Thread: Ryan Gordon Is Fed Up, FatELF Is Likely Dead

  1. #101
    Join Date
    Oct 2009
    Posts
    2,117

    Default

    Quote Originally Posted by deanjo View Post
    Sorry guys, but there is no way that you are going to convince me that making sure every damn distro and packager are playing by the same set of rules is easier then giving a "one-size-fits-all" solution. Ever think that there is good motivation behind Ryan's efforts? After all he is the leading porter of games for OS X and linux.
    How is it relevant if every distro and packager plays by the same rules? It is up to THAT PARTICULAR distro to be consistent with their OWN package manager, and it is up to the packager to ensure that THEIR PACKAGE meets the packaging specifications of the distro they are targeting.

  2. #102
    Join Date
    Oct 2009
    Posts
    2,117

    Default

    Quote Originally Posted by smitty3268 View Post
    Specify a package format that just stores everything into a zip file like that and try to get people to use it. Once enough 3rd party programs start relying on that functionality he can then make the argument that it would be better if integrated into the ELF specification.
    Interesting thought...
    You know, you could actually do this with RPM quite easily. Just use a "noarch" and set it to extract its files into /lib32, /bin32, /lib64, and /bin64 (and wherever else is needed), and in the post stage of the install, create a symlink from /bin/whatever -> /bin??/whatever. Or even better, create a script in /bin/whatever that does if (arch=whatever) run --/bin??/whatever. The functionality *already exists*, lets call it fatRPM!

  3. #103
    Join Date
    Oct 2009
    Posts
    2,117

    Default

    Quote Originally Posted by deanjo View Post
    Well first of all zip is a piss poor way of trying to preserve permissions and such so throw that idea out of the window as far as using zip. Of course you can check arch with a script again hoping that the script maintainer had enough foresight to see all possible reporting of the arch type
    Whatever unforseen arch there may be is guaranteed not to be within your fatelf anyways, so this is a pointless argument.
    and of course you hope like hell everybody is using the same shell and paths. Many present day installers already try that mojo sad fact is that they fail after a while. (For example many Loki installer games fail because of changing device names, old incompatible libs, etc).
    In this regard, it doesn't make ANY difference if you are using elf or fatelf, since you STILL depend on the same device names, up to date libraries, etc.

    As far as the "Once enough 3rd party programs start relying on that functionality" it's the chicken and egg thing.
    Since the first chicken was born of some sub-chicken species that LAID EGGS, the egg came first. FACT.
    Seeing that Ryan is the big porter for many of these commercial games, I would have to say he finds it desirable for his situation. He's carried the porting torch for linux for quite a while now, it would be a deep shame to lose his contributions. As it is he already ports more for the mac then linux, this gives him just another reason to discourage development for linux.
    Huh? So you propose to let him spoil linux just to keep him HAPPY enough to keep porting games? Maybe if his games are so important to you, you should pull out your cheque book and buy him a new car or some hookers or something.

  4. #104
    Join Date
    Oct 2009
    Posts
    2,117

    Default

    Quote Originally Posted by Veerappan View Post
    Some people seem to be forgetting the proportions of code to data in the application space we're talking about here (primary commercial games).

    Lets say you've got a universal binary that handles x86, x86_64, and PPC 32-bit. This binary is for World of Warcraft (a randomly picked example). The original release of WoW contained ~3.5GB of installed data, and a binary which was only several megabytes in size. Let's pick a (probably exaggerated) number of 50MB for the X86 executable. The main point here is that textures/models/sounds/scripts make up the bulk of the installed game, not the executable.

    Now lets image that Blizzard wants to release a *nix WoW client. There's no way that they'll convince the maintainers of a dozen different distributions to include their closed-source application in the default repositories for each distibution, so they have to release it themselves. They could package it as rpm, deb, or several of a dozen different formats, but each of those would be something they'd have to support separately.

    With this FatELF concept, they could compile the game on x86, x86_64, and PPC once, and create a single archive containing all 3 architectures. The total size of the archive (before compression) would be 3.5GB + 50MB*3 = 3.65GB, which is a far cry from the 3 * 3.5GB you seem to be fearing.

    This archive could either contain copies of the libraries needed to run the game on each architecture (whose versions could explicitly be chosen for compatibility with the game code and known stability), or you could take the easy way out and just statically compile the executable. Either way, as pointed out before, by including only copies of required libraries, the need for a FULL set of 32-bit compatibility libraries is avoided, and only relevant libraries are included.

    This method may lead to a larger installed application than including only a single architecture, but it's not the monumental waste of space that some people are making it out to be.

    Personally, I like the idea of FatELF, but it seems that I'm in the minority with deanjo here.
    Or you could package your files as...
    executable x86_64
    executable x86_32
    executable PPC64
    data

    pick data + one of the 3 and install them. Done.

  5. #105
    Join Date
    Jan 2009
    Location
    UK
    Posts
    331

    Default

    Quote Originally Posted by droidhacker View Post
    Since the first chicken was born of some sub-chicken species that LAID EGGS, the egg came first. FACT.
    Chickensaur evolves into Chicken at level 25, actually

  6. #106
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by droidhacker View Post
    That would depend on how retarded your distro is behaving (i.e. how many unneeded 32bit libs they install just for the fun of it).

    In other words, you can have an *entirely* 64bit system and it works just fine. If you need to run some specific 32bit program, you install ONLY the required dependencies instead of *ALL* 32bit packages provided by the platform, which is what fatelf would do (in addition to installing ALL of the packages for ALL platforms that *aren't even compatible* -- like ARM, SPARC, PPC, PPC64, etc.).
    See that is exactly why I said it is a shame....

    Fatelf solves the problem where you can have only the required 32bits libs needed and nothing else, and it stores them in a convenient way also abides traditional filesystem layout. It removes the need for a whole bunch of stupid symlinks and makes finding and linking libraries a hell of a lot easier.

    The problem with it is that make doesnt really support crosscompiling in an efficiant elegant manner. Cross compiling on most distros is hackish at best, and on others is a collection of complicated scripts that need special sandboxed environments to run in. The fact is that fatelf is an excellent idea to solve amajor problem, but it doesnt address the massive deficiency in cross compiling support in linux as it exists today.

    make needs to be completely rewritten or replaced.

  7. #107
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by droidhacker View Post
    ... so the goals are to make everybody need to download 5 or 10 DVDs to install from instead of just one that matches their architecture? That sure sounds simple to me....
    LMAO you clearly don't get it at all, try a few extra meg.

    Whatever unforseen arch there may be is guaranteed not to be within your fatelf anyways, so this is a pointless argument.
    Script checks for x86-64, system reports back x86_64, fail

    In this regard, it doesn't make ANY difference if you are using elf or fatelf, since you STILL depend on the same device names, up to date libraries, etc.
    Which would be handled by the fatELF supporting libraries that are maintained by the distro.

    A distro would only have to maintain their fatELF libraries this way not them having to maintain every single commercial application out there. Next

    Interesting thought...
    You know, you could actually do this with RPM quite easily. Just use a "noarch" and set it to extract its files into /lib32, /bin32, /lib64, and /bin64 (and wherever else is needed), and in the post stage of the install, create a symlink from /bin/whatever -> /bin??/whatever. Or even better, create a script in /bin/whatever that does if (arch=whatever) run --/bin??/whatever. The functionality *already exists*, lets call it fatRPM!
    Again not every distro follows the same directory structure especially when it comes to /lib structure.

    How is it relevant if every distro and packager plays by the same rules? It is up to THAT PARTICULAR distro to be consistent with their OWN package manager, and it is up to the packager to ensure that THEIR PACKAGE meets the packaging specifications of the distro they are targeting.
    And how often does that happen? Extremely rare when dealing with commercial apps. If you can find me a commercial app that has a distro specific package for all the flavors of distros out there then you can start talking about reality of execution. To this date this has not happened. There is a reason why vendors like nvidia have stopped making distibution specific install packages the vender can't do it nor will all the distro's put the effort to make such packages let alone host them. Again reality check time.

    That would depend on how retarded your distro is behaving (i.e. how many unneeded 32bit libs they install just for the fun of it).

    In other words, you can have an *entirely* 64bit system and it works just fine. If you need to run some specific 32bit program, you install ONLY the required dependencies instead of *ALL* 32bit packages provided by the platform, which is what fatelf would do (in addition to installing ALL of the packages for ALL platforms that *aren't even compatible* -- like ARM, SPARC, PPC, PPC64, etc.).
    I have yet to see any mainstream package system that does not install a bunch of unneeded linked libs for a application. You might of heard of this but it's called dependency hell.

    As well, FatElf could only install what is needed and a situation such as it isntalling libs for "ARM, SPARC, PPC, PPC64, etc" is highly unlikely if the application isn't even supported in that architecture. Again keep this within the realm of reality and within context.
    Last edited by deanjo; 11-05-2009 at 04:44 PM.

  8. #108
    Join Date
    Oct 2008
    Posts
    895

    Default

    Quote Originally Posted by deanjo View Post
    If you can find me a commercial app that has a distro specific package for all the flavors of distros out there then you can start talking about reality of execution. To this date this has not happened.

    http://www.sidefx.com/index.php?opti...ice&Itemid=277

    Packages for Ubuntu 9.04 + 7.04 + 7.10, Debian Lenny + Etch, RHEL 4 + 5, OpenSuse 10.2, and a generic 32 bit for the weirdo's on arch, slackware, and gentoo.

  9. #109
    Join Date
    Dec 2007
    Location
    /dev/hell
    Posts
    297

    Default

    don't know if someone already linked it, but Diego Pettenò made an explanation why it was not accepted:
    http://blog.flameeyes.eu/2009/11/04/...r-be-on-a-diet

  10. #110
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,795

    Default

    Quote Originally Posted by Vighy View Post
    don't know if someone already linked it, but Diego Pettenò made an explanation why it was not accepted:
    http://blog.flameeyes.eu/2009/11/04/...r-be-on-a-diet
    Yeah, I already posted that but everyone in here just continues talking the same stuff all over again and totally ignoring that article.

    Go figure (yes, this is the interwebs.)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •