I think the *right* place to solve this is at the package layer, and that is precisely where it has already been done. I'm glad this waste of a project was rejected.
Announcement
Collapse
No announcement yet.
Ryan Gordon Is Fed Up, FatELF Is Likely Dead
Collapse
X
-
Originally posted by deanjo View PostPretty much any mac user that has used universal binaries would disagree with you.
Comment
-
Originally posted by Yuma View PostAhh so this is a solution to one problem being applied to a completely different situation, regardless of whether or not there really is a problem to solve? No wonder it makes no sense.
I also have to say that this is great motivation for Ryan to say "Screw linux development, concentrate on the OS X ports"Last edited by deanjo; 04 November 2009, 01:45 AM.
Comment
-
Originally posted by deanjo View PostHow is it any different? One package for multiple arch.
Comment
-
Originally posted by hubick View PostThe Mac only has two architectures to deal with. Linux works on, what, like 25. And Linux distro's already have solutions in place (like multi-lib and different repo's) to deal with this problem.
Multi-lib is fine but usually the bloat that comes with doing such is much larger then what a universal binary approach would add. Installing 32-bit libs often installs a shitload of 32-bit compatibility libs that are not really needed.
Comment
-
Originally posted by deanjo View PostHow is it any different? One package for multiple arch.
I also have to say that this is great motivation for Ryan to say "Screw linux development, concentrate on the OS X ports"
For starters, lets go with the fact that on Linux most people get their software through a package manager, which completely voids the entire reason for this projects existence. So we've already narrowed down it's usefulness to only projects that are deployed by 3rd parties as binaries, like Flash. Then there's the fact that even in the Flash case, it would be a better solution for the users if they've packaged their project in rpms or debs which again would take care of this already. So it's just good for those oddball companies that refuse to play by Linux rules for whatever reason.
Then there's the fact that Linux supports dozens of architectures. Which ones are the FatELF's supposed to support? I'm guessing you'd end up with a huge mismatch, with a bunch of packages just for x86, others for x86/x64, and still more with added support for PowerPC, ARM, etc. The Mac's version only had to support 2. It seems like a huge mess just waiting to happen.
I'm sure there's tons of other differences as well, but the bottom line is, what does this really solve? What problem are you having that this would fix? Saying it worked on the Mac is not an answer, it's dodging the question by putting up a straw man.
Comment
-
Originally posted by smitty3268 View PostAre you saying you really can't see the differences between Linux and OSX?
For starters, lets go with the fact that on Linux most people get their software through a package manager, which completely voids the entire reason for this projects existence. So we've already narrowed down it's usefulness to only projects that are deployed by 3rd parties as binaries, like Flash. Then there's the fact that even in the Flash case, it would be a better solution for the users if they've packaged their project in rpms or debs which again would take care of this already. So it's just good for those oddball companies that refuse to play by Linux rules for whatever reason.
Then there's the fact that Linux supports dozens of architectures. Which ones are the FatELF's supposed to support? I'm guessing you'd end up with a huge mismatch, with a bunch of packages just for x86, others for x86/x64, and still more with added support for PowerPC, ARM, etc. The Mac's version only had to support 2. It seems like a huge mess just waiting to happen.
I'm sure there's tons of other differences as well, but the bottom line is, what does this really solve? What problem are you having that this would fix? Saying it worked on the Mac is not an answer, it's dodging the question by putting up a straw man.
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).Last edited by deanjo; 04 November 2009, 02:29 AM. Reason: Editted to correct the number of archs universal binaries handle
Comment
-
Why would kernel devs risk infringing on patents 5432937 and 5604905 to fix a problem that doesn't exist. Thats the impression I got for the lack of desire to get the code pushed upstream. Not only that, but because it involves patents, its a taboo topic.
What I am disappointed about is that I will never see the creativity involved in the creation of a fatelf logo.
From the patent point of view, I see much less contreversy here:
< quote >
Based on feedback from this list, the patent concern that I'm not qualified to resolve myself, and belief that I'll be on the losing end of the same argument with the glibc maintainers after this, I'm withdrawing my FatELF patch. If anyone wants it, I'll leave the project page and patches in place at http://icculus.org/fatelf/ ...
Thank you everyone for your time and feedback.
--ryan.
< / quote >
Comment
Comment