Floppinux – An Embedded Linux on a Single Floppy, 2025 Edition

Nostalgia and historical context

  • Many reminisce about the physicality of floppies: drive noise, multi‑disk installs (Slackware on dozens of disks), and classic “demo” OSes like the QNX GUI-on-a-floppy and MenuetOS/KolibriOS.
  • People recall floppy‑based Linux distros and router/firewall systems (e.g., floppyfw, CoyoteLinux, muLinux, Tom’s Root Boot) and how 486/Pentium‑era machines served as routers and gateways.
  • Some note the floppy as an “iconic unit”: just big enough to be useful, small enough to make fitting a real OS a serious challenge, unlike 700MB CD images.

Technical constraints and clever tricks

  • The described persistence trick—mounting the FAT filesystem read‑write and bind‑mounting it as home—is praised as a space‑saving hack, though some prefer a second floppy for writes.
  • Others suggest avoiding FAT entirely: treat free space as a raw block area, or append data (e.g., a tar archive) to the initramfs and only serialize on shutdown.
  • Extended floppy formats (e.g., 21 sectors/track for ~1.68MB) are proposed to gain extra space; Linux tools can create these formats.
  • Questions arise about whether formatting is needed at all; some speculate about directly loading the kernel from raw sectors and embedding the command line.

Filesystem robustness and FAT vs journaling

  • One side argues journaling is overrated and that FAT, widely used in embedded devices, is “good enough” if drivers are careful and fsck runs after failures.
  • Others counter that without journaling, mid‑operation crashes can easily leave inconsistent metadata (e.g., broken renames, mismatched directory entries/FAT chains), requiring full checks.
  • There’s detailed debate on how DOS historically ordered FAT writes (two FAT copies, directory update last) vs how modern Linux VFAT drivers actually behave; consensus is that mainline Linux does not implement the more careful strategy.

Old hardware, 32‑bit support, and practicality

  • Several describe trying to revive 32‑bit or even 386/486 systems and finding that hardware power isn’t the main barrier; modern software stacks and drivers have largely left them behind.
  • Problems cited: lack of modern 32‑bit binaries, dropped video drivers (leaving only slow VGA), non‑hybrid ISOs that don’t boot from USB, and difficulty playing even low‑res video.
  • Some recommend NetBSD/OpenBSD or very small distros (e.g., delicate Linux, busybox‑based setups) for such machines; others note that “i386” in distro docs no longer means 386/486‑class CPUs are truly supported.

Kernel, floppy, and compatibility issues

  • Contrary to some memories, Linux still includes a floppy driver, though it’s described as “basically orphaned.”
  • i486 support is slated to be dropped in kernel 6.15; some suggest just using a still‑supported LTS like 6.12 rather than backporting.
  • One report says Floppinux fails to boot on a real 486 DX2, apparently due to BIOS memory map (E820h) assumptions in SYSLINUX; works on newer systems but not certain older ones.

Motivations and relevance

  • Some question the point of a floppy‑based Linux in 2025 given scarce hardware; others frame it as a pure challenge and learning project, akin to climbing an already‑climbed mountain.
  • A recurring theme is affection for small, efficient systems in contrast to perceived modern bloat, even if projects like Floppinux are mostly nostalgic and educational rather than practically useful.