[haiku-development] Re: A modest (FatELF) proposal
- From: Landon Fuller <landonf@xxxxxxxxxxxxxx>
- To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
- Date: Mon, 19 Nov 2012 18:16:53 -0500
On Nov 19, 2012, at 16:04, pulkomandy <pulkomandy@xxxxxxxxxxxxx> wrote:
>> It would also make it very easy for 3rd party applications to just
>> distribute one binary for every architecture, instead of limiting it to x86
>> because cross-compilation is extra-effort. That would really be useful for
>> PPC/ARM, so developers don't need to set up extra crosstools, but already
>> have all libs they need on-board for other archs.
>
> This, on the other hand, doesn't sound ok to me.
> The developper would have to test and debug binaries on all the
> architectures he wants to release. This means having a development
> environment on each platform, building and testing binaries there. THEN,
> when they work, package and release them. The packaging can then be done
> at package manager level and has no need for fatelf.
Our workflow on iOS and Mac OS X is to perform all development on our primary
desktop architecture. If you've accounted for endianness and 64-bit issues
(which is easier when you're building all the time for the targets and getting
warnings due to type mismatches, etc), then 9.99 times out of 10, the binary
works on other target machines the first time.
In fact, this is arguably a feature, in that developers are unlikely to have
more esoteric hardware on hand (m68k, MIPS, or even ARM). Being able to easily
target new architectures means that they can produce binaries for architectures
that would otherwise not have them, relying on user testing to validate the
results. It's not ideal, but it's difficult to bootstrap a new target platform,
and anything that makes it easier on users and developers makes it all the more
likely that it'll be supported, even if minimally at first.
> As for the size increase : one of the selling points of Haiku is that it
> is lightweight. Fat binaries are adding extra weight to it for a purpose
> I'm not sure is that useful : being able to use an Haiku installation on
> different CPUs. You can drag and drop your apps, but not a full
> partition because the bootloader (and possibly the partition scheme of
> the disk) would be different.
> The size inclrease was not too important for Apple because they had at
> most 3 architectures in the same package (PPC, x86, x86-64). On Haiku we
> have :
> * x86-gcc2
> * x86-gcc4
> * ARM
> * x86-64
> * PPC
> * 68k
>
> And the list could be growing (MIPS, ...). That's already 6 archs to
> support, which starts to have a significant impact on the size of
> packages even if there is a lot of data.
> To me, this means we WILL be wasting space on disk, and download
> bandwidth, for no practical purpose. It means Haiku wouldn't fit on a CD
> or an 1GB USB stick anymore, for example.
FatELF is really just a mechanism to handle compatibility issues over time and
reduce the costs in supporting architectures (including gcc2/gcc4 on just
x86-32/x86-64), rather than a mandated distribution strategy; it can be used in
whatever combination of resource consumption and ease-of-use makes sense. I
expect that most use will be centered in a few primary architectures, with more
specialized deployments for other architectures. There's really nothing to stop
you from producing a mixed x86-32/x86-64/ARM installation CD, and additional
CDs for other architectures.
In this context, I think it's notable that we have (give or take) 20 years of
history by which we can evaluate the various strategies being discussed here,
and see how they've played out across a multitude of operating systems over
time. There are some common trends that have emerged in various types of
systems, with a lot of smart people spending a lot of time on the problems, and
some things that have proven to be effective for the very different use cases
across open-source and commercial/binary software distribution. I hesitate to
discount the weight of that evidence, and I also think there's room for both
strategies.
Cheers,
Landon
Other related posts:
