[haiku-development] Re: FatELF on Haiku?

On Nov 7, 2009, at 1:50 PM, PulkoMandy wrote:

We definitely don't want to support all of them. And FatELF is not
needed to do so anyway. Look at mplayer under linux : at runtime it
will detect CPU abilities and replace some parts of the code
(time-critical sections) with optimized ones. There is no need to
duplicate the whole code in a FatELF binary.


Well, you have to support some of them, right?
I know how mplayer does it and I can tell you it's a mess. Every such program deals with this in a different way, similar in principle but different. VLC does it differently, xine does it differently. I don't like it. Plus there ARE cases where runtime detection is not possible, for example the Eigen2 C++ math library provides compile time vectorization for particular SIMD engines (SSE/SSE2/SSE3 and I myself provided the Altivec backend and soon I hope the ARM NEON backend too). Since it's a C++ template library, there is NO way to do runtime detection and provide the best version for each SIMD unit. In that case, you just have to provide different binaries... unless one goes for a solution like FatELF. 


And if you strip it in the end, why would you download all the
versions in the first place ?
You don't have to strip it at all in the cases you mentioned. Btw, binaries/executables are seldom the major percentage of a filesystem. Arch-independent stuff like desktops /videos/mp3/text files usually take up much more of disk space than binaries. At least that's the case in my linux systems. The complete OS takes less than 1GB, but all the rest 
takes in excess of 50GB.


It sure was a convenient solution for Mac OS X transition from PPC to
x86, but note they removed all ppc support _before_ switching to x64,
in order not to have 3 archs at the same time. They can have binary
twice as big as needed, but not 3x... In the long term it's not a good
solution. Things like LLVM, with JIT compiling for the local CPU, are
better solutions for this kind of things...
You are mistaken, Fat/Universal binaries ppc support is NOT removed on MacOS X, only the ppc binaries INSIDE. A third party can still quite easily provide universal binaries which include ppc support. The infrastructure is still there, they just stopped compiling ppc support in. FWIW, I'm talking about the infrastructure here as well, Haiku might also include only one arch for a long time, before another port is brought up to par with x86. Still, I think it's good to discuss this particular feature, because I think it's worth discussing. In the end it's up to the developers that make most of the decisions, but to be frank I like this concept so much 
that I might commit myself to working on the haiku port.


Once you strip it, you can't share it with other people anymore. This
is one of the things I find stupid in the linux world : free software
is supposed to allow you to share your software with any people, and
once you try so, it does not work because of stupid binary
compatibility problems and library versions...
Which are problems easily solved by FatELF as this was precisely one of the reasons 
Ryan started work on this, at least according to his website.


Disk space is not a problem when you have a 500GB hard disk on a PC.
But an ARM device may be some embedded things with less than 1GB of
disk, and you don't want to waste space... There are other, cleaner
ways to solve it, like a package manager knowing the infos about the
hardware, or downloading a small installer that you run and determines
the best binary for your CPU.
I was under the impression that Haiku was against the idea of a package manager in the sense used in the Linux world. Even so, one would need separate repositories for every arch supported which also increases repository complexity and disk space. 

Regards

Konstantinos

Other related posts: