Linked by Thom Holwerda on Thu 5th Nov 2009 23:05 UTC
Permalink for comment 393128
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
More News »
Sponsored Links



Member since:
2005-07-18
I appreciate the premise and intention behind this idea and believe that it merits further (non-volatile) discussion. But the sheer number of architectures supported by Linux might make fat binaries impractical.
Apple maintains one MacOSX distribution. They implemented fat binaries because it made business sense -- facilitating a product line conversion from PPC to x86 in a manner least confusing to the customer. The universal binary (adding x64) is a logical and consistent extension to their prior approach, as it assists in their x86-to-x64 push. Previously supported architectures will likely be phased out over time (Apple's PPC won't be around forever).
Linux supports far more architectures than OSX, and when was the last time support was phased-out for a specific architecture? I can't imagine how they'd consolidate all base-install packages on one CD or DVD considering how little room is left at present without fat binaries. Even if you could squeeze them all on there, you have to consider the impact that fat binaries would have on distribution update servers. The file sizes would be doubled (or more).