Linked by Thom Holwerda on Thu 5th Nov 2009 23:05 UTC
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 393132
To view parent comment, click here.
To read all comments associated with this story, please click here.
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
in reply to "RE: Always On the Cards"
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).
RE[3]: Always On the Cards
by asdf on Fri 6th Nov 2009 04:41
in reply to "RE[2]: Always On the Cards"
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.
RE[2]: Always On the Cards
by segedunum on Fri 6th Nov 2009 13:46
in reply to "RE: Always On the Cards"
Member since:2005-07-06
What's complicated about Linux deployment of binaries? Companies interested only have to provide RPMs and DEBs for RedHat and Ubuntu, and a statically compiled "catch all" version for the rest. Given that homogeneity is not the word that defines Linux, there are no solutions for a non existant problem. This is the way Linux works, like it or not.
That's why few ISVs are motivated to package for Linux distributions even now. No one wants to do it. Deployment is a PITA. It is on any platform. It's a massive cost in time, effort and resources for testing and supporting multiple scenarios that ISVs just can't do it.
To suggest packaging for umpteen different package managers, multiplied by umpteen different distributions multipled by umpteen different distributions versions and then suggesting they have a statically linked catch-all is so f--king stupid it isn't even funny. No ISV is doing that now and no one will do it ever.
To suggest that isn't complicated.........well, you've never done serious deployment in your life.
...and that leads people to offer different choices for different purposes: thats what makes Linux so great, that most companies can't get their head around.
I don't see any choice here...........
RE[3]: Always On the Cards
by sbenitezb on Fri 6th Nov 2009 15:28
in reply to "RE[2]: Always On the Cards"
Member since:2005-07-22
To suggest packaging for umpteen different package managers, multiplied by umpteen different distributions multipled by umpteen different distributions versions
You don't have to support all of them. There's no point in supporting something like Arch, for example. But Ubuntu, SuSe, Red Hat and Debian. The fact that we use 64bit computers today, and ARM processors in the near future complicates things. We are not in a wintel 32bits only world anymore. What do you expect ISVs to do about that?
and then suggesting they have a statically linked catch-all is so f--king stupid it isn't even funny. No ISV is doing that now and no one will do it ever.
You seem to have a crystal ball.
To suggest that isn't complicated.........well, you've never done serious deployment in your life.
It isn't complicated for a company to devote 1 person for each platform to do the packaging. Unless they are cheap. Or you really think that all that magic must be done by just one single guy? Come on, distro packagers package thousands of binaries for different architectures even for free. Red Hat guys get paid to do it on a mass scale, how come Adobe cannot devote some resources into providing its "quality" software for Linux? You think they are not interested because it's difficult to package and support. They are not interested because they see no money in doing it, and of course they are not doing it for free.
"...and that leads people to offer different choices for different purposes: thats what makes Linux so great, that most companies can't get their head around.
I don't see any choice here........... " [/q]
So narrow minded.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2005-07-22
What's complicated about Linux deployment of binaries? Companies interested only have to provide RPMs and DEBs for RedHat and Ubuntu, and a statically compiled "catch all" version for the rest. Given that homogeneity is not the word that defines Linux, there are no solutions for a non existant problem. This is the way Linux works, like it or not.
It's a community, a free community where individuals share a common goal (one way or the other) and that goal is to have a free and working OS, the best possible. Where you have freedom, you have choice, and that leads people to offer different choices for different purposes: thats what makes Linux so great, that most companies can't get their head around.