| |||||||||||||
SELF: Anatomy of an (alleged) failureSELF: Anatomy of an (alleged) failurePosted Jun 23, 2010 21:53 UTC (Wed) by Tara_Li (subscriber, #26706)In reply to: SELF: Anatomy of an (alleged) failure by cmccabe Parent article: SELF: Anatomy of an (alleged) failure
Um... FatELF - Ok, we're going to have one binary that runs on... i386, x86-64, itanium, a dozen different ARMs, Sparcs... I think Alpha support got dropped somewhere along the way... IBM Sys/390s... You know, somewhere along that line, you're dropping a 2 or 3 gigabyte binary file on my machine just to run Mozilla?
Bah. I really don't see a good case for FatELF.
(Log in to post comments)
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 3:23 UTC (Thu) by ccurtis (guest, #49713) [Link]
It seems fairly plain to me. Look at all the different flavors of ARM and MIPS and VIA and A3 and Atom cores that people carry around in their handheld computers. When the day comes that you don't have to depend on an iStore or the App Market or Obj-C or Dalvik or whatever, and you just want to ship your 5MB game binary with its 500MB of textures without making your customers dig through lists of every cell phone model in existence, FatELF might actually be rather handy.
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 5:01 UTC (Thu) by bronson (subscriber, #4806) [Link]
IF that day comes (I'm skeptical -- architectural diversity seems to be increasing), I expect kernel devs will be more receptive to it.
Until then, it seems like you're trying to merge the solution before the problem even exists.
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 13:37 UTC (Thu) by ccurtis (guest, #49713) [Link]
I'm not necessarily arguing for FatELF, but isn't anticipating the market and having a solution before something becomes a problem the very definition of innovation?
Personally, I like the idea of having solutions rather than problems.
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 17:11 UTC (Thu) by chad.netzer (✭ supporter ✭, #4257) [Link]
Except when you guess wrong, and burden everyone with a worse problem. (Many examples exist, though RAMBUS jumps to mind)
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 20:02 UTC (Thu) by vonbrand (subscriber, #4458) [Link]
Then ship the application as a
SELF: Anatomy of an (alleged) failure Posted Jun 25, 2010 15:45 UTC (Fri) by intgr (subscriber, #39733) [Link]
As has been mentioned above, this problem is already solved. Shell scripts run on pretty much all Linux devices and are perfectly adequate for choosing the right binary to execute.
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 17:49 UTC (Thu) by pj (subscriber, #4506) [Link]
I'm less worried about Mozilla and more interested in lib* so that a FatELF-aware gcc/linker can do cross compiles easily. Ever tried doing a build for an embedded box like ppc or arm on a non-ppc or arm machine? The toolchain is *painful* because you have to make sure to like all the right libs from all the right places for the destination arch plus you have to tell them that although on the current system they're found in /lib/arch-foo/, on the destination system they'll be in /lib ... total PITA. FatELF would provide a solution to that: all the libs are in... /lib. Done, period, end of story, picking the right segment out of the ELF file is something that the linker should do (and complain if it's not found!).
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 19:13 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
What will it take to create them?
Specifically, I have libfoo installed for i386 from my distro. I now want to install libfoo for mips (or even worse: the powerpc variant of the day). Does it mean I have to modify /usr/lib/libfoo.so.1 as shipped by my distro?
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 19:43 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
If only it worked that easily.
sometimes you need different versions of compilers for different architectures.
go read Rob Landley's blog for ongoing headaches in cross compiling.
having the results all in one file is trivial compared to all the other problems.
SELF: Anatomy of an (alleged) failure Posted Jun 25, 2010 15:59 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Your "FatELF aware toolchain" is the sum total of the separate cross-toolchains, so there is no real gain here. That said, GCC has been the cross compiler of choice for most of its life, so it has quite a set of options for doing what you want, cleanly. Not your everyday use, sure, so it can be rough going.
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 23:36 UTC (Thu) by Tet (subscriber, #5433) [Link] You know, somewhere along that line, you're dropping a 2 or 3 gigabyte binary file on my machine just to run Mozilla? Bah. I really don't see a good case for FatELF.Yeesh. Everyone is bringing up countless examples of where FatELF could be abused and claiming that it's therefore useless. But no one has mentioned that FatELF solves some very real problems, problems that I encounter on a fairly regular basis. Here's a hint: if you don't want to use fat binaries, then don't. I'll guarantee you that even if it were included upstream, Fedora/Debian/OpenSUSE/Ubuntu etc would continue to release architecture specific images. But for some of us, that's not good enough, and FatELF is one solution to the problem. If people want to suggest others, I'm all ears...
SELF: Anatomy of an (alleged) failure Posted Jun 25, 2010 13:54 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Please enlighten us to the recurring problems you have that FatELF would solve. For my part, I haven't run into any situation that didn't have a simple solution which did not involve changing the kernel and the whole buildchain. Doing so adds so much overhead that the problem would have to be humongous to make it worth my while, but you can leave that consideration out if you like.
SELF: Anatomy of an (alleged) failure Posted Jun 25, 2010 18:57 UTC (Fri) by Tet (subscriber, #5433) [Link] Please enlighten us to the recurring problems you have that FatELF would solveThere's only one ~/.mozilla/plugins Since my $HOME is NFS mounted across a mix of 32-bit and 64-bit OSes, I'm basically screwed. 32-bit plugins won't work with a 64-bit Firefox and vice versa. Yes, you could argue the application should be fixed, but the same applies to gimp and to countless other apps, which means an awful lot of applications are out there to fix. If I could get a fat libflashplayer.so, for example, everything would Just Work™. I'm not suggesting that the whole OS should be fat binaries/shared libraries. But I'd like the option to use them where they make sense, as I believe they do here. Again, if you have a simple solution that doesn't involve FatELF or something similar, please let me know.
SELF: Anatomy of an (alleged) failure Posted Jun 25, 2010 19:35 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
before you worry about getting a fat libflashplayer.so there first needs to be a 64 bit libflashplayer.so for you to use and merge with the 32 bit one.
users of 64 bit desktops still user the 32 bit libflashplayer.so run though a ndiswrapper layer.
so this is not a case where FatELF would help in practice.
even in theory, firefox doesn't have to have the plugin binaries under ~/ so if you don't install them there and instead install them in one of the other places that it can live you would be able to NFS mount $HOME without a problem.
the same thing goes for any application that uses plugins. the plugin binaries should be able to be installed outside of $HOME. If they can be, then the application can work if $HOME is shared.
SELF: Anatomy of an (alleged) failure Posted Jun 25, 2010 21:16 UTC (Fri) by Tet (subscriber, #5433) [Link] Ye gods, does it really take much effort to see past the lack of a 64-bit flash plugin (which incidentally, I do have, even if it's been discontinued by Adobe)? The same applies to any plugin. Forget that I mentioned flash, and think instead about a java plugin or an acroread plugin, or any other plugin you care to think of.the same thing goes for any application that uses plugins. the plugin binaries should be able to be installed outside of $HOME. If they can be, then the application can work if $HOME is shared. Yes, but here in the real world, they're not. Even if you could find a suitable location that would be writeable by a non-privileged user, it would mean changing the applications, and as I mentioned, there are many, many of those. Simply making a fat shared library possible would be a much easier and cleaner solution, and would have negligible impact on those that didn't want or need to use it. I don't understand why so many are opposed to it.
SELF: Anatomy of an (alleged) failure Posted Jun 25, 2010 21:27 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
re: 64 bit flash
you do realize that the version you have is vunerable to exploits that are being used in the wild. Adobe decided to discontinue the 64 bit version instead of fixing it.
a fat plugin is only useful if you also have fat libraries everywhere. This directly contridicts posts earlier that said not to worry about the bload as the distros would still ship non-fat distros.
by the way, do you expect plugs to work across different operating systems as well so that you can have your $HOME NFS mounted on MACOS as well? where do you draw the line at what yo insist is needed?
SELF: Anatomy of an (alleged) failure Posted Jun 25, 2010 21:40 UTC (Fri) by Tet (subscriber, #5433) [Link] Yes, I do know about the vulnerabilities with 64-bit flash. But like I said, this conversation isn't about flash. Despite your claim, I don't need fat libraries everywhere. On the 32-bit machines, I would already have the corresponding 32-bit libraries installed. And on the 64-bit machines, I'd have the 64-bit libraries installed. No, I don't use OS X, nor is it relevant to this discussion. If a particular approach solves a problem (as it will here), it's probably worthwhile, even if it doesn't solve every problem. I say again, why are you so anti fat binaries/libraries?
SELF: Anatomy of an (alleged) failure Posted Jun 25, 2010 22:17 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
people supporting want a Fat binary that's only fat enough for your particular system, but claim that having fat binaries would solve distribution problems because there wouldn't need to be multiple copies.
these two conflict, if you are going to support FAT binaries for every possible combination of options the distribution problem is much larger. If you are going to want the fat binary to support every possible system in a single binary it's going to be substantially larger.
it's not that I am so opposed to the idea of fat binaries as it is I don't see them as being that useful/desirable. the problems they are trying to address seem to be solvable by other means pretty easily, and there is not much more than hand waving over the cost.
SELF: Anatomy of an (alleged) failure Posted Jun 26, 2010 7:33 UTC (Sat) by Tet (subscriber, #5433) [Link] I'm not claiming fat binaries solve any particular distribution problem, nor do I believe that their existence means that fat binaries must cover every possible combination. In fact, just shipping a combined ia32 and x86_64 binary would cover 99% of the real world machines. But even if you don't want to ship a fat binary, it's not hard to envisage tools that would allow an end user to create a fat binary from two (or more) slim ones.I've outlined a case where it would be both useful and desirable to have them, and to date, I haven't seen any sensible alternatives being proposed.
SELF: Anatomy of an (alleged) failure Posted Jun 26, 2010 15:08 UTC (Sat) by vonbrand (subscriber, #4458) [Link] Just use two binary packages, with non-architecure-dependent stuff exactly the same, and arrange for the package manager to manage files belonging to several packages. RPM does this, and it works. No need to screw around with the kernel, no need to have 3 versions of the package (arch 1, arch 2, fat).
SELF: Anatomy of an (alleged) failure Posted Jun 26, 2010 18:20 UTC (Sat) by tzafrir (subscriber, #11501) [Link]
It works for rpm when all those shared fiels are identical in every package.
But what you want to do here is that rpm will be able to merge files from different packages into a single file on disk. This won't work.
SELF: Anatomy of an (alleged) failure Posted Jun 26, 2010 21:49 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
and fat binaries won't work in cases where you need different config file options for different architectures and the config file is on a shared drive
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 16:11 UTC (Sun) by Tet (subscriber, #5433) [Link] <paxman>Answer the question! </paxman> Your "solution" doesn't solve the problem where application plugins are concerned. Firstly, the majority them are not installed using the system package manager in the first place, and secondly, it's utterly irrelevant anyway. You can't package the achitecture specific bits separately, because the application only looks for them in one place. As I said right at the start, it would be good to fix the applications, but there are a hell of a lot of them. Fat binaries would solve the problem. Your suggestions wouldn't, without first also patching the apps.
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 17:17 UTC (Sun) by nix (subscriber, #2304) [Link]
FatELF wouldn't help with OSX anyway: OSX doesn't use ELF.
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 17:15 UTC (Sun) by nix (subscriber, #2304) [Link]
Ah, right. So we don't need completely arbitrary fat binaries at all: we need a 'fat dlopen()'.
I suspect -- though it's a kludge -- you could do this with an LD_PRELOADed wrapper around dlopen() which tweaks the filename appropriately, and slight changes to the downloading parts of e.g. firefox to put its dynamically loaded stuff in per-arch subdirectories when autodownloaded. dlopen() is not a hidden symbol so should be vulnerable to interposition.
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 17:55 UTC (Sun) by Tet (subscriber, #5433) [Link] So we don't need completely arbitrary fat binaries at all: we need a 'fat dlopen()'To solve this particular problem, yes. But then Ryan's FatELF release supported dlopen()ing fat shared libraries.
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 20:36 UTC (Sun) by nix (subscriber, #2304) [Link]
Yes, but if that's all you need to do, the kernel side of FatELF is superfluous.
SELF: Anatomy of an (alleged) failure Posted Jun 28, 2010 8:53 UTC (Mon) by Tet (subscriber, #5433) [Link]
Oh agreed, and in this particular case, it's not necessary. However, there are other situations where full fat binaries might be a win. I just get extremely annoyed by people claiming that the whole concept of multi-arch binaries is useless just because they happen to not have a valid use for them, and are unable to see that others might have.
SELF: Anatomy of an (alleged) failure Posted Jun 28, 2010 13:22 UTC (Mon) by nix (subscriber, #2304) [Link]
The attitude appears to be 'distributors don't need them therefore they are useless'. This seems, to me, more than a little shortsighted...
|
|||||||||||||