| |||||||||||||
SELF: Anatomy of an (alleged) failureSELF: Anatomy of an (alleged) failurePosted Jun 25, 2010 18:57 UTC (Fri) by Tet (subscriber, #5433)In reply to: SELF: Anatomy of an (alleged) failure by vonbrand Parent article: SELF: Anatomy of an (alleged) failure Please enlighten us to the recurring problems you have that FatELF would solve There'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.
(Log in to post comments)
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...
|
|||||||||||||