Как обычно, в LKML началась дискуссия по поводу добавления FatELF в ядро. Райан Гордон показал основные преимущества, которые должна дать поддержка FatELF:
- Distributions no longer need to have separate downloads for various platforms. Given enough disc space, there's no reason you couldn't have one DVD .iso that installs an x86-64, x86, PowerPC, SPARC, and MIPS system, doing the right thing at boot time. You can remove all the confusing text from your website about «which installer is right for me?»
- You no longer need to have separate /lib, /lib32, and /lib64 trees.
- Third party packagers no longer have to publish multiple .deb/.rpm/etc for different architectures. Installers like MojoSetup benefit, too.
- A download that is largely data and not executable code, such as a large video game, doesn't need to use disproportionate amounts of disk space and bandwidth to supply builds for multiple architectures. Just supply one, with a slightly larger binary with the otherwise unchanged hundreds of megabytes of data.
- You no longer need to use shell scripts and flakey logic to pick the right binary and libraries to load. Just run it, the system chooses the best one to run.
- The ELF OSABI for your system changes someday? You can still support your legacy users.
- Ship a single shared library that provides bindings for a scripting language and not have to worry about whether the scripting language itself is built for the same architecture as your bindings.
- Ship web browser plugins that work out of the box with multiple platforms.
- Ship kernel drivers for multiple processors in one file.
- Transition to a new architecture in incremental steps.
- Support 64-bit and 32-bit compatibility binaries in one file.
- No more ia32 compatibility libraries! Even if your distro doesn't make a complete set of FatELF binaries available, they can still provide it for the handful of packages you need for 99% of 32-bit apps you want to run on a 64-bit system.
- Have a CPU that can handle different byte orders? Ship one binary that satisfies all configurations!
- Ship one file that works across Linux and FreeBSD (without a platform compatibility layer on either of them).
- One hard drive partition can be booted on different machines with different CPU architectures, for development and experimentation. Same root file system, different kernel and CPU architecture.
- Prepare your app on a USB stick for sneakernet, know it'll work on whatever Linux box you are likely to plug it into.
- Prepare your app on a network share, know it will work with all the workstations on your LAN.
Алан Кокс не согласился с доводами Райана Гордона и разобрал всё по пунктам:
От: Alan Cox <alan@lxorguk.ukuu.org.uk> Кому: Ryan C. Gordon <icculus@icculus.org> Копия: Måns Rullgård <mans@mansr.com>, linux-kernel@vger.kernel.org Тема: Re: FatELF patches... Дата: Mon, 2 Nov 2009 00:01:47 +0000 (05:01 YEKT) Lets go down the list of "benefits" - Separate downloads - Doesn't work. The network usage would increase dramatically pulling all sorts of unneeded crap. - Already solved by having a packaging system (in fact FatELF is basically obsoleted by packaging tools) - Separate lib, lib32, lib64 - So you have one file with 3 files in it rather than three files with one file in them. Directories were invented for a reason - Makes updates bigger - Stops users only having 32bit libs for some packages - Third party packagers no longer have to publish multiple rpm/deb etc - By vastly increasing download size - By making updates vastly bigger - Assumes data files are not dependant on binary (often not true) - And is irrelevant really because 90% or more of the cost is testing - You no longer need to use shell scripts and flakey logic to pick the right binary ... - Since the 1990s we've used package managers to do that instead. I just type "yum install bzflag", the rest is done for me. - The ELF OSABI for your system changes someday? - We already handle that - Ship a single shared library that provides bindings for a scripting language and not have to worry about whether the scripting language itself is built for the same architecture as your bindings. - Except if they don't overlap it won't run - Ship web browser plugins that work out of the box with multiple platforms. - yum install just works, and there is a search path in firefox etc - Ship kernel drivers for multiple processors in one file. - Not useful see separate downloads - Transition to a new architecture in incremental steps. - IFF the CPU supports both old and new - and we can already do that - Support 64-bit and 32-bit compatibility binaries in one file. - Not useful as we've already seen - No more ia32 compatibility libraries! Even if your distro doesn't make a complete set of FatELF binaries available, they can still provide it for the handful of packages you need for 99% of 32-bit apps you want to run on a 64-bit system. - Argument against FatELF - why waste the disk space if its rare ? - Have a CPU that can handle different byte orders? Ship one binary that satisfies all configurations! - Variant of the distribution "advantage" - same problem - its better to have two files, its all about testing anyway - Ship one file that works across Linux and FreeBSD (without a platform compatibility layer on either of them). - Ditto - One hard drive partition can be booted on different machines with different CPU architectures, for development and experimentation. Same root file system, different kernel and CPU architecture. - Now we are getting desperate. - Prepare your app on a USB stick for sneakernet, know it'll work on whatever Linux box you are likely to plug it into. - No I don't because of the dependancies, architecture ordering of data files, lack of testing on each platform and the fact architecture isn't sufficient to define a platform - Prepare your app on a network share, know it will work with all the workstations on your LAN. - Variant of the distribution idea, again better to have multiple files for updating and management, need to deal with dependancies etc. Waste of storage space. - We have search paths, multiple mount points etc. So why exactly do we want FatELF. It was obsoleted in the early 1990s when architecture handling was introduced into package managers.
Stay tuned!
