On Tue, 2005-04-12 at 20:51, Matthew Miller wrote: > You're missing a huge part of the picture. Having lilo the package (even > though as you note, it's not really maintained) might not be much, but it > requires a lot of complicated kludgy infrastructure in the installer, and in > mkinitrd, etc., and makes kernel updates very fragile. Based on a quick browse of the sources: The functionality is mostly encapsulated in two neat little programs called grubby and new-kernel-package that are part of the mkinitrd package. Sensibly, they are mostly generic, with small tables and small code sections devoted to Grub, Yaboot, Lilo, Silo, Zipl, and Elilo. Anaconda also has small amounts of loader specific code - mostly in the UI. up2date has boot-loader specific code, but only because it doesn't use grubby (except for grub). The true cost of supporting Lilo in up2date is negligable because grubby should be doing the work. Thus Lilo costs a couple of hundred lines of simple code - simple code which already exists. Anaconda and Grubby and Up2date already handle several kinds of boot loaders and that generality must be retained in order to support the several different architectures. I do not see any massive savings resulting from removing any complicated kludgy infrastructure in the installer. OK, now you can bring out the clue-by-fours. What complicated kludgy infrastructure that's needed for Lilo but not needed for all the other boot loaders did I miss? --Mike Bird