Chris Tillman wrote: > Would it be worthwhile to standardize on 1 kernel floppy, 1 root > floppy, with strictly minimal stuff on the root system just to be > able to access floppies/CDs and start the installer, and then put off > any remaining floppy involvement until after boot is complete - to > load any other needed modules for specific cases as needed. Do note that there are some machines (certain USB floppy drives in my experience) where the kernel is not able to read a root filesystem off a second floppy, but a root on the same floppy works since the loader uses the BIOS to read the initrd. > Even on architectures where the kernel and root fits on 1 floppy, I > think it would be worthwhile code-wise to standardize on 2. How many > people are actually going to burn floppies? And 2 is not much harder > than 1. That way, our code can be modular, our instructions can be > consistent, etc. Additional floppies or a CD would also be required > for additional language support beyond choosing the language. d-i's modular code is the only reason we have any hope of fitting it on one floppy at all. I don't see how two floppies improves modularity. Instructions that leave a set of systems uninstallable are probably worse than mildly complicated ones, especially if the install manual for d-i is generated on a per-arch basis, so the number of floppies to burn can be substituted in at build time. Two floppies are really much harder to manage than one, for the user. I'm not so attached to a single floppy install that I'd advocate making the installer worse in general for it, but there seem to be plenty of avenues left if the floppy is almost full: - trim fat (stuff that has wandered into the image and need not be there, stuff not built with -Os, stuff that needs a redesign anyway) - switch to a smaller libc, such as uclibc - find a better filesystem/compression for the initrd - change the build system to produce two or three specialized floppy images (for install over network only, over cd only, with floppies only) with different mixes of udebs on them I think that the one floppy size constraint has helped keep d-i small and light, and I have not seen undue stressing about size constraints on this list. When it does come up, as in the first mail on this thread it is someone noticing some breakage in the system, like libc reduction not working right, or cdebconf.udeb being built with an extra frontend that really needs to be in its own udeb. The one floppy constraint has led to some IMHO good design choices throughout d-i, including: - udebs - use of frontend and backend modules for cdebconf If we didn't have a size constriant, this project could easily look a lot more like PGI. -- see shy jo  For exmple, my picturebook (RIP) had a usb floppy with no kernel driver. Even if it had a driver, it would be interesting to make the kernel load a filesystem from a USB floppy on boot, without hotplug and so on being available.  Much as the boot-floppies 6 floppy set used to be a ton harder to deal with than are the 1 or 2 peices of install media most people install with today. And not just 6x as hard either..
Description: PGP signature