On Monday 08 February 2010, Cyril Brulebois wrote: > If you were to build a netboot-gtk image using DirectFB, and to > compare with one using X11, one gets: > DirectFB: 9191 extents written (17 MB) > X11 : 11239 extents written (21 MB)
Let's first look at image size in a bit more detail. I'll use the i386 mini.iso as example (as Cyril did above). The absolute sizes of images will vary, but any size change should also be valid for other images and installation methods (and the relative size changes even for other arches). Note that for size increase we only have to look at the images as everything needed for that is included in the image. All sizes are based on current udebs from the archive and Cyril's "alpha1" udebs. I used mklibs for all images (i.e. library reduction was active). The non-graphical mini.iso is 8.8 MB. Almost 5.5 MB of that is the kernel (2.2 vmlinuz; 3.3 modules, mostly networking). 2.4 is D-I userspace included from udebs. The remainder is userspace copied from the host system (reduced libs) and boot loader stuff. The directfb based mini.iso is 17.5 MB, almost twice the size. The increase of 8.7 MB is: - TTF fonts: ~3 MB (>15% of the increase!) Note that the first G-I images included a 17 MB (!) fonts tarball, and for fewer languages than we currently have. Almost all efforts to reduce the size of the DirectFB based installer has gone into that. - libdirectfb: 350 kB - libgtk-directfb: ~1.8 MB - libglib: ~1.5 MB - all other libs/packages: ~2 MB As can be seen libglib and libgtk are major contributors to the size increase and probably only a very small part of both is actually used. Changing from kbd-chooser to console-setup adds 170 kB to that image. The current X.Org based mini.iso is 21 MB, almost 20% bigger. The increase of 3.3 MB is: - libdirectfb removal: -/- 350 kB - libx11: ~1 MB - xserver-xorg-core: ~0.9 MB - xkb-data: ~0.8 MB - all other libs/packages: ~0.9 MB So, excluding the fonts, graphical support using FrameBuffer costs ~5.7 MB. And graphical support using X.Org costs ~9.2 MB. That's a factor 1.6. Why image size is important --------------------------- Let me first say that I don't think the current size needs to be a blocker, but I also think it's very important to reduce it as much as possible. 1) every MB pushes other packages off the 1st full CD and DVD This may not seem like a major issue, but it's something that causes the debian-cd team headaches. The space on especially the first CD is at a premium. We've always aimed to have the 1st CD install a working desktop environment *and* support the server tasks. There are other images where we either aim to keep as small as possible, or where we try to fit different arches or desktops together. In some cases it's a tight fit. And even if it does fit in itself an increase may e.g. push packages needed to support specific languages off an image. 2) makes loading the image for netboot installs slower 3) reduces portability Some arches (sparc, arm netbooks) have limitations on the size of the image that can be loaded. Why memory usage is less important ---------------------------------- Essentially because we've made the choice that if a user wants to do an install on a memory constrained system, he's not going to be very interested in having graphical support anyway. So we're more strict when it comes to size and memory usage for the regular images than for G-I images and real lowmem installs are only supported for the regular images. This also explains why G-I images have "speakup" accessibility support while regular images do not. We do have a lower limit for the graphical frontend coded into rootskel-gtk, but that is only so that systems that have e.g. 64 MB (and thus can handle the G-I initrd size, but not run the graphical frontend) will gracefully fall back to the newt frontend instead of crashing. How image size could be reduced ------------------------------- In general: many small savings can add up to a significant reduction. * try to avoid some dependencies altogether Two udebs I noticed are libgcrypt11 and libgpg-error0; together 250 kB. Is the first really needed? If it is, maybe a lot of algorithms could be disabled? IIUC libgpg-error0 contains error messages. Somehow I doubt their display would ever be relevant for D-I. Also note that for udebs static compilation of libs is an option that can be (carefully) considered [1]! This will automatically reduce size as well as only used symbols will be compiled in. * disable every option in X and libraries that the installer does not need I'm thinking of things like 3D and acceleration. * library reduction Currently only libc, libnewt and libslang get reduced. Library reduction was something that was absolutely required for floppy-based images, which explains why relatively small libs like newt and slang are included. For libc the reduction is temporary: only for the initrd and early installation stages. During "anna" we load the full libc-udeb as other components loaded during anna will need symbols not included in the reduced version. But for libs exclusively used by cdebconf (like newt and slang) the gain is permanent as we can be certain no additional symbols will be needed later, so there's no need to load the full versions later. This means it also helps reduce memory usage for the full installation. So IMO we should now look at library reduction for the largest "extra" libs used in the graphical installer: libgtk, libglib, libx11. I think a huge reduction should be possible, possibly even making the image smaller than the current directfb based one [2]. Library does complicate D-I releases as it currently means the libs will be taken from the host system at build time (to ensure a version match with the .pic file used in the reduction). > Some things that might need thinking about: > - Maybe gtk could benefit from a stripped-down flavour instead of > using the 'shared' one; that might lead to depending on fewer X > libraries; other patches (gtk2-engines, rootskel-gtk come to mind) > might need tweaking in this case, so as to use the proper .pc > file. > - Maybe libgpg-error and libgcrypt11 could be replaced by > libcrypto0.9.8-udeb (already used by openssh). One downside is that > libcrypto0.9.8-udeb is bigger. These are definitely worth thinking about. Wild thought: could the openssh udebs be made to use libgcrypt instead? [1] In general only if only one other udeb depends on the lib. [2] But doing the same on the directfb image would of course still result in a smaller image... -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002190746.38372.elen...@planet.nl
