| |||||||||||||
SELF: Anatomy of an (alleged) failureSELF: Anatomy of an (alleged) failurePosted Jun 23, 2010 23:29 UTC (Wed) by dlang (✭ supporter ✭, #313)In reply to: SELF: Anatomy of an (alleged) failure by drag 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.
as for transitioning, install a 64 bit system and 32 bit binaries, as long as you have the libraries on the system they will work. fatelf doesn't help you here (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)
distros would still have to compile and test all the different copies of their software for all the different arch's they support, they would just combine them together before shipping them (at which point they would have to ship more CDs/DVDs and or pay higher bandwidth charges to get people copies of the binaries that don't do them any good)
(Log in to post comments)
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 0:37 UTC (Thu) by drag (subscriber, #31333) [Link]
> 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..
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.
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 24, 2010 1:24 UTC (Thu) by cesarb (subscriber, #6266) [Link]
> your hard drive may be large enough to double the size of everything stored on it, but mine sure isn't
And some are very small indeed. One of my machines has only a 4 gigabyte "hard disk" (gigabyte, not terabyte). It is a EeePC 701 4G. (And it is in fact a small SSD, thus the quotes.)
There is also the Live CDs/DVDs, which are limited to a fixed size. Fedora is moving to use LZMA to cram even more stuff into its live images (https://fedoraproject.org/wiki/Features/LZMA_for_Live_Images). Note also that installing from a live image, at least on Fedora and IIRC on Ubuntu, is done by simply copying the whole live image to the target disk, so the size limitations of live images directly influence what is installed by default.
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 24, 2010 9:06 UTC (Thu) by ncm (subscriber, #165) [Link]
This, very incidentally, is one of the reasons I object to Gnome forcing a dependency on Nautilus into gnome-session. In practice, Gnome works fine without Nautilus, once you jimmy the gnome-session package install and poke exactly one gconf entry. That saves 60M on disk, and a gratifying amount of RAM/swap. It's only arrogance and contempt that makes upstream keep the dependency.
Disconnecting nautilus from gnome session Posted Jun 24, 2010 20:56 UTC (Thu) by speedster1 (subscriber, #8143) [Link]
I know this is off-topic... but would you mind giving a little more detail on how to remove the nauilus dependency?
Disconnecting nautilus from gnome session Posted Jun 26, 2010 9:56 UTC (Sat) by ncm (subscriber, #165) [Link]
In gconf-editor, go to desktop/gnome/session/, and change required_components_list to "[windowmanager,panel]".
While we're way, way off topic, you might also want to go to desktop/gnome/interface and change gtk_key_theme to "Emacs" so that the text edit box keybindings (except in Epiphany, grr) are Emacs-style.
Contempt, thy name is Gnome.
Getting back on topic, fat binaries makes perfect sense for shared libraries, so they can all go in /lib and /usr/lib. However, there's no reason to think anybody would force them on you for an EEE install.
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 24, 2010 12:30 UTC (Thu) by Cato (subscriber, #7643) [Link]
Nobody is suggesting that everyone should have to double the size of their binaries - most distros would use single architecture binaries. FatELF is a handy feature for many special cases, that's all.
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 24, 2010 17:03 UTC (Thu) by chad.netzer (✭ supporter ✭, #4257) [Link]
Which reminds me, why aren't loadable binaries compressed on disk, and uncompressed on the fly? Surely any decompression overhead is lower than a rotating storage disk seek, and common uncompressed binaries would get cached anyways. I suppose it's because it conflicts with mmap() or something.
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 24, 2010 19:40 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
it all depends on your system.
do you have a SSD?
are you memory constrained (decompressing requires that you have more space than the uncompressed image)
do you page out parts of the code and want to read in just that page later (if so, you would have to uncompress the entire binary to find the appropriate page)
what compression algorithm do you use? many binaries don't actually compress that well, and some decompression algorithms (bzip2 for example) are significantly slower than just reading the raw data.
I actually test this fairly frequently in dealing with processing log data. in some condititions having the data compressed and uncompressing it when you access it is a win, in other cases it isn't.
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 25, 2010 0:14 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257) [Link]
Yeah, I made reference to some of the gotchas (spindles, mmap/paging). Actually, it sounds like the kind of thing that, should you care about it, is better handled by a compressed filesystem mounted onto the bin directories, rather than some program loader hackery.
Still, why the heck must my /bin/true executable take 30K on disk? And /bin/false is a separate executable that takes *another* 30K, even though they are both dynamically linked to libc??? Time to move to busybox on the desktop...
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 25, 2010 0:38 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
re: size of binaries
http://www.muppetlabs.com/~breadbox/software/tiny/teensy....
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 25, 2010 2:41 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257) [Link]
Yes, I'm familiar with that old bit of cleverness. :) Note that the GNU coreutils stripped /bin/true and /bin/false executables are more than an order of magnitude larger than the *starting* binary that is whittled down in that demonstration. Now, *that* is code bloat.
To be fair getting your executable much smaller than the minimal disk block size is just a fun exercise. Whereas coreutils /bin/true may actually benefit from an extent based filesystem. :) Anyway, it's just a silly complaint I'm making, though it has always annoyed me a tiny bit.
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 25, 2010 12:25 UTC (Fri) by dark (subscriber, #8483) [Link] Yes, but GNU true does so much more! It supports --version, which tells you all about who wrote it and about the GPL and the FSF. It also supports --help, which explains true's command-line options (--version and --help). Then there is the i18n support, so that people from all over the world can learn about --help and --version. You just don't get all that with a minimalist ELF binary.
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 25, 2010 15:38 UTC (Fri) by intgr (subscriber, #39733) [Link]
Indeed, I use those features every day! ;)
PS: Shells like zsh actually ship builtin "true" and "false" commands
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 29, 2010 23:03 UTC (Tue) by peter-b (subscriber, #66996) [Link]
So does POSIX sh. The following command is equivalent to true:
:
The following command is equivalent to false:
! :
I regularly use both when writing shell scripts.
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 27, 2010 16:42 UTC (Sun) by nix (subscriber, #2304) [Link]
There are two separate binaries because the GNU Project thinks it is confusing to have single binaries whose behaviour changes depending on what name they are run as, even though this is ancient hoary Unix tradition. Apparently people might go renaming the binaries and then get confused when they don't work the same. Because we do that all the time, y'know.
(I think this rule makes more sense on non-GNU platforms, where it is common to rename *everything* via --program-prefix=g or something similar, to prevent conflicts with the native tools. But why should those of us using the GNU toolchain everywhere be penalized for this?)
Disk space (was: SELF: Anatomy of an (alleged) failure) Posted Jun 27, 2010 16:46 UTC (Sun) by nix (subscriber, #2304) [Link]
The size, btw, is probably because the gnulib folks have found bugs in printf which the glibc folks refuse to fix (they only cause buffer overruns or bus errors on invalid input, after all, how problematic could that be?) so GNU software that uses gnulib will automatically replace glibc's printf with gnulib's at configure time. (That this happens even for things like /bin/true, which will never print the class of things that triggers the glibc printf bugs, is a flaw, but not a huge one.)
And gnulib, because it has no stable API or ABI, is always statically linked to its users.
26Kb for a printf implementation isn't bad.
|
|||||||||||||