| |||||||||||||
SELF: Anatomy of an (alleged) failureSELF: Anatomy of an (alleged) failurePosted Jun 24, 2010 0:37 UTC (Thu) by drag (subscriber, #31333)In reply to: SELF: Anatomy of an (alleged) failure by dlang Parent article: SELF: Anatomy of an (alleged) failure
> you happily run 32 bit userspace on a 64 bit kernel, you already don't have to care about this.
I do have to care about it if, in the future, I want to run a application that benefits from 64bit-ness.
Some operations are faster in 64bit and many applications, such as games, already benefit from the larger address space.
> (it may help if your libraries were all fat, but I fail to see how that's really much better than having /lib32 /lib64 (your hard drive may be large enough to double the size of everything stored on it, but mine sure isn't)
Yes. That is what I am talking about. Getting rid of architecture-specific directories and going with FatElf for everything.
Your wrong in thinking that having 64bit and 32bit support in a binary means that your doubling your system's footprint. Generally speaking the architectural-specific files in a software package is small compared to the overall size of the application. Most ELF files are only a few K big. Only rarely do they get up past a half a dozen MB.
My user directory is about 4.1GB large. Adding Fatelf support for 32bit/64bit applications would probably only plump it up a 400-600 MB or so..
(Log in to post comments)
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 7:56 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
If it really is such low overhead and as useful as you say, Why don't you (alone or with help from others who believe this) demonstrate this for us on a real distro.
take some distro (say ubuntu since it supports multiple architectures) download the repository (when I did this a couple years ago it was 600G, nowdays it's probably larger so it make take $150 or so to buy a USB 2TB drive, it will take you a while to download everything), then create a unified version of the distro, making all the binaries and libraries 'fat' and advertise the result. I'm willing to bet that if you did this as a plain repackaging of ubuntu with no changes you would even be able to get people to host it for you (you may even be able to get Cononical to host it if your repackaging script is simple enough)
I expect that the size difference is going to be larger than you think (especially if you include every architecure that ubuntu supports, not just i486 and AMD64), and this size will end up costing performance as well as having effects like making it hard to create an install CD etc.
I may be wrong and it works cleanly, in which case there will be real ammunition to go back to the kernel developers with (although you do need to show why you couldn't just use additional ELF sections with a custom loader instead as was asked elsewhere)
If you could do this and make a CD like the ubuntu install CD, but one that would work on multiple architectures (say i486, AMD64, powerPC) that would get people's attention. (but just making a single disk that does this without having the rest of a distro to back it up won't raise nearly the interest that you will get if you can script doing this to an entire distro)
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 12:12 UTC (Thu) by nye (guest, #51576) [Link]
>If it really is such low overhead and as useful as you say, Why don't you (alone or with help from others who believe this) demonstrate this for us on a real distro.
Because the subject of this article already did that: http://icculus.org/fatelf/vm/
It's not as well polished as it could be - I got the impression that he didn't see much point in improving it after it was dismissed out of hand.
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 20:47 UTC (Thu) by MisterIO (guest, #36192) [Link]
IMO the problem with FatELF isn't that nobody proved that it was doable(because they did that), but that nobody really acknowledeged that there's any real problem with the current situation.
|
|||||||||||||