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
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...
Reply to: