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.
Announcement
Collapse
No announcement yet.
Ryan Gordon Brings Universal Binaries To Linux
Collapse
X
-
Originally posted by Remco View PostHow 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.
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
-
Originally posted by Ex-Cyber View PostI 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.Last edited by pvtcupcakes; 22 October 2009, 11:58 AM.
Comment
-
Originally posted by kraftman View Post+1
PPC? Thanks, I don't use it and I probably never will.
Comment
-
Commercial Stuff
Originally posted by Remco View PostHow 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.
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
-
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
-
Originally posted by AHSauge View PostNot 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?").
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
-
Originally posted by Adriano ML View PostThis 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
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
Comment