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

Companies interested only have to provide RPMs and DEBs for RedHat and Ubuntu, and a statically compiled "catch all" version for the rest.


Obviously, you know nothing about the subject, yet you feel compelled to comment anyways....
If you did know something about this you would know that for an application beyond the most trivial you would have to provide RPM for SuSE, Mandriva and RedHat, DEB for Debian and Ubuntu each of these in 32 bit and 64 bit versions (that is a total of 10).
Then lets say it has a UI so you want to provide a Gnome and a KDE version, so now you are at 20.
Then you app may have sound, so you provide one for ALSA and one for PA, and now you are at 40.
So 40 binaries to cover just the basics, if you app is just a little bit more complicated and has Hardware discovery and a Daemon that gets activated at install time then you will have to make your binaries not only distribution dependent but also dependent on the version of the distribution.

This is the point where most ISVs says "F**K THAT" and decides not to support Linux.

But the binary is just the last part in a long chain of actions, if you are an ISV that gives a S**T about quality you have to test your app before you release and that of course means testing on all different versions, including update versions of the different distros, so you do not only have to provide 40 binaries you have to test for about 200 to 300 different distribution scenarios.

This is the way Linux works, like it or not.


Linux has unfortunately been conquered by some businesses that has a strong commercial interest (RedHat, etc.) in keeping this mess going for as long as possible.
Even open source projects suffer from this, because the first thing to go when faced with this many possible scenarios is quality control. It really is unfortunate that many Open Source projects works better and has a higher quality on windows than on Linux (whatever flavor you prefer).

Reply Parent Score: 5

RE[3]: Always On the Cards
by asdf on Fri 6th Nov 2009 04:41 in reply to "RE[2]: Always On the Cards"
asdf Member since:
2009-09-23

So 40 binaries to cover just the basics, if you app is just a little bit more complicated and has Hardware discovery and a Daemon that gets activated at install time then you will have to make your binaries not only distribution dependent but also dependent on the version of the distribution.


Going back to the subject, how would fat binary solve any of the above problems? If anyone really wants single binary for different archs for whatever reason, there's always "#!" and if you play smart with it, you can pack everything into a single file and unpack and execute the right binary on demand.

The fat/universial binary thing is just some weird thing apple did. Maybe they didn't have common scripting mechanism across old and new systems. Maybe it just fitted better with their multi data stream file system. There's no reason to do it the same way when about the same thing can be achieved in much simpler way and it's not even clear whether it's a good idea to begin with.

Reply Parent Score: 2

RE[4]: Always On the Cards
by Slambert666 on Fri 6th Nov 2009 07:09 in reply to "RE[3]: Always On the Cards"
Slambert666 Member since:
2008-10-30

Going back to the subject, how would fat binary solve any of the above problems? If anyone really wants single binary for different archs for whatever reason, there's always "#!" and if you play smart with it, you can pack everything into a single file and unpack and execute the right binary on demand.


Sure you can brew together all kinds of custom solutions that could / should / would maybe work, so now you have just doubled the number of problem areas:

1. The program itself.
2. The install system for the above program.

It is so sad that today it is much, much easier to make a new distro (an opensuse or ubuntu respin) that contains your program as an addition, than it is to make an installer that will work for even a single distro across versions ....

A fat binary is not a complete solution, it is not even a partial solution but it is perhaps a beginning to a solution.

The fat/universial binary thing is just some weird thing apple did. Maybe they didn't have common scripting mechanism across old and new systems. Maybe it just fitted better with their multi data stream file system. There's no reason to do it the same way when about the same thing can be achieved in much simpler way and it's not even clear whether it's a good idea to begin with.


Maybe they just wanted the install process to be easier for their users .... and ISV's ...

Reply Parent Score: 1