Linked by Thom Holwerda on Thu 5th Nov 2009 23:05 UTC
Permalink for comment 393188
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/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
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
More News »
Sponsored Links



Member since:
2009-09-23
1. The program itself.
2. The install system for the above program.
Modifying the binary format, updating kernel and then all the tool chains, debuggers and system utilities are gonna be much harder than #2.
Sure, agreed. Linux is facing different problems compared to proprietary environments.
But here I completely fail to see the connection. Really, fat binary support in kernel or system layers doesn't make whole lot of difference for the end users and we're talking about the end user experience, right?
The real problem is not in the frigging binary file format, it's in differences in libraries, configurations and dependencies and fat binary contributes nothing to solving that. Also, it's a solution with limited scalability. It sure works fine for apple but it will be extremely painful to use with increasing number of binaries to support.