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[1], 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[2], 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
[1] 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.
[2] 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..
Attachment:
pgpU_zdeNhr_e.pgp
Description: PGP signature