Recent Features
| |||||||||||||
Quotes of the weekQuotes of the weekPosted Nov 6, 2009 16:58 UTC (Fri) by Tet (subscriber, #5433)In reply to: Quotes of the week by clugstj Parent article: Quotes of the week No, FatELF came about to solve some very real problems that can't be solved otherwise. It happens to also be an option for some other things that can be solved by other means (for example, package management). But it solved a problem, which now will remain unsolved due to the unwillingness of some kernel developers to actually think about the issue.
(Log in to post comments)
Quotes of the week Posted Nov 6, 2009 17:33 UTC (Fri) by farnz (guest, #17727) [Link] So, what problems are there? Please, demonstrate them with a comparison using an existing user-space implementation of FatELF - you don't need kernel support for a binary format (binfmt_misc exists for a reason). You only need kernel support for a binary format if your critical binaries you need to mount a filesystem and execute the dynamic loader are in that format - this is why ELF is in-kernel. Beyond that, a userspace dynamic loader can do what the in-kernel handling does, thus proving the value of FatELF in the real world. Once you've got that proof (e.g. every distro using ld.fatelf.so), then kernel inclusion is worth discussing.
Quotes of the week Posted Nov 6, 2009 20:34 UTC (Fri) by Tet (subscriber, #5433) [Link] Largely, I think we're agreeing. The specific example I was thinking of (and indeed, which I've been bitten by in the last few weeks) is ~/.mozilla/plugins. binfmt_misc won't help there, but ld.fatelf.so would. I was arguing for FatELF as a concept, not necessarily for the specific kernel implementation. Remember, there's more to FatELF than just the kernel patches. Ryan also provided patches for glibc, binutils and gdb. But Ulrich has refused to consider a FatELF ld.so, so we're basically screwed.
Quotes of the week Posted Nov 6, 2009 22:29 UTC (Fri) by farnz (guest, #17727) [Link] No, we're not agreeing at all. You appear to be under the impression that because I'm not savaging you, I agree - right now, I am undecided, but slightly biased against FatELF, after my limited experience of OS X "universal" binaries (which appear to not work properly, in as much as my experience of them is that the binaries don't work on PPC or x86, and the developers neither supply source, not support whichever architecture you have in hand beyond compiling the universal binary). binfmt_misc is the kernel side of the support infrastructure you need to make an ld.fatelf.so work transparently to the end-user. Where's the implementation of ld.fatelf.so? Why do we need it in-kernel now? What problems does it solve that I've experienced, whether in using Linux distributions, in supporting them as part of an end-user product, or in supporting the use of Linux as the only OS on my wife's computer? I'm seeing an awful lot of assumptions on the part of FatELF supporters that everyone has seen the problems they've seen, and, well, I haven't. I see a solution looking to create me the same problems I experienced trying to make binary-only software work on Mac OS X, and I don't like it, but I'd like someone to tell me what the positives are. Thus far, all I see is more code, less testing, and people telling me that I must accept it, because it solves a problem that is better solved elsewhere.
|
|||||||||||||