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 393215
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Always On the Cards
by setec_astronomy on Fri 6th Nov 2009 10:36 UTC in reply to "RE[5]: Always On the Cards"
Member since:

Spot on.

I would like to add that in this discussion, two separate problem fields got mixed up.

The first on is concerned with providing an - ideally ? - unified binary for a range of "hardware architectures", e.g. the ARM notebook / scrabble game example from the comment above comes to mind.
As others have already pointed out, it is difficult to sell the advantages of a "fatELF" while all the costs and problems inherent with such a solution could be avoided if you solve the problem where it actually occurs, namely at the point of software distribution.
If you download, for example, Acrobat reader, the script operating the download form tries to guess the right system parameters and automatically provides the "correct" / "most likely" binary to match your needs. Additionally, advanced users can manually select the right binary for their environment from a - given the number of Linux distros out there - surprisingly small number of binaries and be done with it.

This, plus the possibility to choose an approach similar to the one used by the world of goo developers are less invasive to the target system and are, if done well, more convenient for the end user.

The second, somehow orthogonal, problem set is the large level of dispersion when it comes to what actually is an Linux based operating system (e.g. what is sometimes referred to as "distro" or "dependency hell"). It is imho crucial to get rid of the idea that from the point of view of an ISV, there is something like an "operating system". What the application developer relies on is a set of "sandboxes" that provide the necessary interface for the particular program to run.

In the case of MS Windows or Mac OSX, there is - in essence - a rather small number of "blessed" sandboxes provided by the vendor that allow ISV's to easily target these operating systems. The reason for the small number of these sandboxes is imho related to the fact that there is, essentially, only one vendor deciding what is proper and what is not, e.g. it's more a cultural difference and less a technical one. Failing to address the fact that - for example - Linux based operating systems live and operate in an environment with multiple vendors of comparable influence and importance and multiple, equally valid and reasonable answers to the question of "which components 'exactly' should go into our operating systems and how do we combine them" misses the mark a little bit. Diversity between the different distros is not some kind of nasty bug that crept into our ecosystem, it is a valid and working answer to the large number of different needs and usage patterns of end users. Moreover, it is kind of inevitable to face this problem sooner or later in an where players rely on compability at the source code level and the (legal and technical) ability to mix and mash different code bases to get their job done.

If an ISV is unwilling or unable to participate in this ecosystem by providing source-level compability (e.g. open sourcing the necessary parts that are needed to interface the surrounding environment), they have a number of options at their hands:

- Target a cross-platform toolkit like for example Qt4, thus replacing a large number of small sandboxes with one rather large one, which is either provided by the operating system (e.g. distro) or statically linked.

- Use a JIT compiled / interpreted / bytecoded run-time environment, again abstracting large numbers of sandboxes into the "interpreter" and again rely on the operating system to provide a compatible rte or additionally ship your own for a number of interesting platforms.

- Use something like for example libwine

- Rely on a reasonable and conservative base set of sandboxes (e.g. think LSB) and carry the remainder of your dependencies in the form of statically linked libraries with you. There are problematic fields, like for example audio - Skype and Flash are notoriously problematic in this department - but the binary format of an executable strikes me to be a rather bad place to fix this problem.

Reply Parent Score: 6