The old way, we had one kernel, optimized for the lowest denonimation of ia32 machine. Ie, i386. We then modified the drivers that were compiled into the kernel.
Now, using an initrd, we no longer need to compile different variations of drivers and modules into and out of the kernel. We can compile almost everything as a module, and use the initrd to insert the required drivers at boot time. Everyone agrees that using an initrd, allows us to reduce the number of kernel images, and thereby, reduce the load on mirrors, cds, and boot floppy workers. However, by increasing the number of kernel images(which specific cpu optimization does), will not help them in any regard. This supposed initrd, that contains the modules to be inserted, has to have modules that match the kernel being booted. This means they have to be optimized for the same type of cpu. To continue further, this means we can't use a generic initrd, but one that is either created dynamically, at installation time, built from the generic base initrd, and the specific set of matching modules, or, use a prebuilt one, that matches the particular kernel that has been choosen. Now, it doesn't take a genius, to see how this will cascade. For each optimization of a kernel, there will be a full kernel-image.deb. Then, for the boot disks, there will be the individual kernel, and the modules to match it(this is a doubling of space). So, for all the numbers given in this thread(whatever their value), you have to double them. Now, my gut instinct says that, as of this moment in time, no one has addressed the building of this initrd, to use at boot time, AFTER installation. Yes, we may have an installation initrd, but, in almost all circles, that is going to be different that what is used after the system is installed. Has this boot time initrd been constructed? Do we know how we are going to do that? The best way to handle all this, is to train users how to compile a kernel, or, let them pick the optimization they want, and we compile the kernel for them. We could even use a double boot technique, to make sure it works. The new kernel is installed, added to lilo, but not made the default. System reboots, and the user picks the new kernel. IF the kernel works, we switch the default.
