[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Switching g-i from DirectFB to X11 -- image size; library reduction

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 

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 

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 

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...

Reply to: