Linked by Thom Holwerda on Thu 5th Nov 2009 23:05 UTC
Linux As we all know, Mac OS X has support for what is called 'fat binaries'. These are binaries that can carry code for for instance multiple architectures - in the case of the Mac, PowerPC and x86. Ryan Gordon was working on an implementation of fat binaries for Linux - but due to the conduct of the Linux maintainers, Gordon has halted the effort.
Thread beginning with comment 393384
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Comment by Zifre
by MysterMask on Sat 7th Nov 2009 14:35 UTC in reply to "Comment by Zifre"
MysterMask
Member since:
2005-07-12

I have to agree with the kernel guys and Ulrich here. There is a much better way to do it
[..]
This way, you can very easily and simply delete the binaries you don't need, no patches are needed, and it is still user-friendly.


I don't know about FatELF but deleting unwanted binary code is no problem at all with universal binaries on OS X (implementing similar functionality for FatELF should be easy):


The lipo command creates or operates on ``universal'' (multi-architecture) files. It only ever produces one output file, and never alters the input file. The operations that lipo performs are: listing the architecture types in a universal file; creating a single universal file from one or more input files; thinning out a single universal file to one specified architecture type; and extracting, replacing, and/or removing architectures types from the input file to create a single new universal output file.


Since the binary code part is normaly small compared with other resources (sound files, pictures, translations, etc.), thinning out a binary is normally not worth the time (except maybe if you run under very restricted condition like a mobile phone).

However, Linux fanboys simple forget a common use case under Mac OS: copying a application from one system to another. E. g. you copy a universal binary app from a PPC-64 bit system to a x86-32 bit system - a simple drag and drop operation (or use cp if you prefer that). With universal binaries, no problem at all. Everything works. From the user perspective, the system behaves as expected (why should there be any difference between copying a data file or a application binary?).

Compare this with the sad situation under Linux ..

As long as Linux developers care more for HD space an 'the one true way'-wars that ends up in a mess under /usr/<whatever>, the year of Linux on the desktop will occur the same year as commercial fusion power arrives (whenever you ask, it's always another 50 years in the future ;) .

The system adminstrators approach most Linux fanboys adopt may work for server environments or their own tiny world, but not for the masses ..

Reply Parent Score: 2

RE[2]: Comment by Zifre
by Zifre on Sat 7th Nov 2009 15:14 in reply to "RE: Comment by Zifre"
Zifre Member since:
2009-10-04

I don't know about FatELF but deleting unwanted binary code is no problem at all with universal binaries on OS X (implementing similar functionality for FatELF should be easy)

Yes, it is certainly possible and easy to make a command to remove unneeded binaries, but why would you do that when there is a much simpler solution. Power users can selectively delete binaries (e.g. delete arm and powerpc, but keep i686 and x86_64). And their could still be an easy command or menu option for those who don't know or care what architecture they have.

However, Linux fanboys simple forget a common use case under Mac OS: copying a application from one system to another. E. g. you copy a universal binary app from a PPC-64 bit system to a x86-32 bit system - a simple drag and drop operation (or use cp if you prefer that). With universal binaries, no problem at all. Everything works. From the user perspective, the system behaves as expected (why should there be any difference between copying a data file or a application binary?).

Um... couldn't you do this with the shell script solution too? As long as you don't delete any binaries, it will act exactly the same as universal binaries on OSX.

Reply Parent Score: 1

RE[3]: Comment by Zifre
by MysterMask on Sun 8th Nov 2009 17:06 in reply to "RE[2]: Comment by Zifre"
MysterMask Member since:
2005-07-12

Um... couldn't you do this with the shell script solution too? As long as you don't delete any binaries, it will act exactly the same as universal binaries on OSX.


The important word in your sentence is 'could'. And that's why Linux is still so far behind when it comes to desktop solutions for the masses: no user friendly interface standards (I don't talk about the size of icons but the fundamental mechanisms) and an inability to think outside the box (i. e. administrated server environment situations).

E. g. under Mac OS X, grandpa Jo can copy an app from his PPC64 machine to grandma Mary's x86 notebook simply by dragging and dropping a single file and without even thinking about different CPU architectures: grandpa Jo (rightfully!) expects this to work and it does - now, how many apps under Linux right now would support the same use case? Approximately none! Even if it works for some apps, he won't use such a feature because from his view it does not work reliable if it's not supported by all the apps.

So instead of adopting something that might ease the use of Linux, you rather depend on every single app creator to implement his or her own scripting solution (that might or might not work). And instead of making something as installing (and deleting) an app a simple drag-and-drop situation you force everybody to use the "magic" (i. e. incomprehensibly) package manager which normally scatters files around /usr and /opt subdirs and makes it impossible to handle things manually ..

Reply Parent Score: 2