I remember the QNX Demo on a 1.44 MB floppy disk. It booted straight into a full blown window manager and had a basic web browser. That was 1999 and I never saw anything like that afterwards.
Iirc (it's been a while), Interactive Unix (full?) install required some 40 (forty!) 5 1/4" floppies (I believe 1.2MiB) anno 1992 or so. Linux (SLS) install was (a little later) so much smaller, even with X11 and TeX, as it had shared libraries (somewhat new in the *nix world then).
The persistence strategy described here (mount -t msdos -o rw /dev/fd0 /mnt) combined with a bind mount to home is a nice clever touch for saving space.
I don't know if that's also true for data integrity on physical magnetic media. FAT12 is not a journaling filesystem. On a modern drive, a crash during a write is at best, annoying while on a 3.5" floppy with a 33mhz CPU, a write operation blocks for a perceptible amount of time. If the user hits the power switch or the kernel panics while the heads are moving or the FAT is updating, that disk is gone. The article mentions sync, but sync on a floppy drive is an agonizingly slow operation that users might interrupt.
Given the 253KiB free space constraint, I wonder if a better approach would be treating the free space as a raw block device or a tiny appended partition using a log-structured filesystem designed for slow media (like a stripped down JFFS2 or something), though that might require too many kernel modules.
Has anyone out there experimented with appending a tar archive to the end of the initramfs image inplace for persistence, rather than mounting the raw FAT filesystem? It might be safer to serialize writes only on shutdown, would love more thoughts on this.
OpenWrt on some devices such as Turris Omnia writes the squashfs (mounted as RO root fs) in the "root" partition and then, immediately after, in the same partition, it writes a jffs2 (mounted as RW overlayfs). So it can be done.
Over Christmas I tried to actually build a usable computer from the 32-bit era. Eventually I discovered that the problem isn't really the power of the computer. Computers have been powerful enough for productivity tasks for 20 years, excepting browser-based software.
The two main problems I ran into were 1) software support at the application layer, and 2) video driver support. There is a herculean effort on the part of package maintainers to build software for distros, and no one has been building 32 bit version of software for years, even if it is possible to build from source. There is only a very limited set of software you can use, even CLI software because so many things are built with 64 bit dependencies. Secondly, old video card drivers are being dropped from the kernel. This means all you have is basic VGA "safe-mode" level support, which isn't even fast enough to play an MPEG2. My final try was to install Debian 5, which was period correct and had support for my hardware, but the live CDs of the the time were not hybrid so the ISO could not boot from USB. I didn't have a burner so I finally gave up.
So I think these types of projects are fun for a proof of concept, but unfortunately are never going to give life to old computers.
i had an original 7" eeepc from 2007, running archlinux-32 from ~2017, with Xfce and all that, and few months ago updated it.. took me almost a day, going through various rabbit-holes, like 1-2 static-built pacmans and python and manually picking and combining various versions. The result was okay but somehow took more space than before (it has 4G ssd, from which i did have 2gb free, now only 1.5). But it maybe that is not old enough as machine..
"There is a herculean effort on the part of package maintainers to build software for distros, and no one has been building 32 bit version of software for years, even if it is possible to build from source."
This statement must be Linux-only
Pre-compiled packages for i386 are still available for all versions of NetBSD including the current one
The way an ISO is supposed to be made to boot from USB (or HDD, SSD) is to set up the BIOS to boot to the proper type device (or let you select from a boot menu).
Start with a conventional MBR and active FAT32 partition, and make sure it will boot to MS-DOS, this only requires the 3 DOS OS files to be present when the bootsector is a DOS bootsector (which seeks IO.SYS).
Once that's done, then (optionally) copy the DOS bootsector to a file on that FAT32 volume, name the (512 byte) file BOOTSECT.DOS. A disk editor can do this, or carefully use dd in Linux.
I then boot to Windows and use its CLI to run SYSLINUX.EXE (v6.03 on virgin media), to "Syslinux" (verb) the FAT32 volume. You can alternatively do this from Linux. This replaces the DOS bootsector with a Syslinux bootsector that will seek a Syslinux folder instead of seeking IO.SYS. Also writes ldlinux.sys and ldlinux.c32 to the FAT volume.
You do have to be consistent with your Syslinux version, the .C32 files in use must be from the same version of Syslinux that you use to "Syslinux" the FAT volume. And must match the version of Isolinux used to make the ISO. To find out which version of Isolinux was originally used on the ISO, open the ISO in a disk editor and these have big sectors but about the third sector down will be some readable text with the Isolinux version number.
Then copy all the files & folders from the mounted ISO to the FAT volume, change the name of the isolinux folder to syslinux, in the syslinux folder change the name of isolinux.cfg to syslinux.cfg.
A properly prepared distro distributed in ISO form should then boot normally the way it is intended when stored on a FAT filesystem instead.
Show-stoppers can still arise when some live distros have .CFG bootstrings within their Isolinux folder that specify CDROM or other hardcoded deficiencies, for USB you can sometimes specify REMOVABLE after you change the foldername to Syslinux. You can also specify a chosen volume in case it's not picked up by default.
You may need to look at every .CFG file in the Syslinux folder, they are all usually linked, ideally there is only syslinux.cfg but some people make it more complicated than that. Back them up before editing but they are just text files.
Since it’s an 1.44M image I assume they use 3.5” diskettes. The terms floppy and diskette are used as synonyms today, but the different names make sense since floppies are flexible and “floppy”. Diskettinux?
Ok, impressive, but - why?
No current computer has a floppy disk drive anymore.
The Web Page claims building such a disk is a learning exercise, but the knowledge offered is pretty arcane, even for regular Linux users.
Is this pure nostalgia?
I was making routers our of old PCs (486 or early pentiums) with 2 network cards (3com or ne2000) back in 2000 with floppies and CoyoteLinux. Installed 10s of them in the students houses.
I was hoping someone would mention CoyoteLinux. It was my residential router for several years in the early 2000s. My 'disaster recovery plan' consisted of a second floppy disk (which fortunately I never had to use).
There’s something really lovely about this project - especially as they’re using the last kernel from May 2025 before x486 support was removed. It feels like somebody lovingly mending their car for one last time or something similar. (I’m tired but you can probably find a cuter metaphor)
It’s amazing to me that the floppy is still a relevant target unit. Just large enough to be useful, small enough to be a real challenge to use well. I don’t see the same passion for 700MB CDROM distributions, probably because the challenge just isn’t there.
I wonder if formatting the floppy is necessary. Could syslinux or maybe lilo load the kernel directly from raw floppy sectors and have the initrd appended to it and the commad line directly inside the kernel via CONFIG_CMDLINE? I know u-boot can do it, but that's 8+ MB.
As an alternative, isn't ext2 smaller by having no FAT tables?
Reminds me of my first linux distro called damnsmall linux. I think this was used as a first attempt to port linux to the gamecube, but the main team driving the effort ended up going with Gentoo instead.
From the main page:
As with most things in the GNU/Linux community, this project continues to stand on the shoulders of giants. I am just one guy without a CS degree, so for now, this project is based on antiX 23 i386. AntiX is a fantastic distribution that I think shares much of the same spirit as the original DSL project. AntiX shares pedigree with MEPIS and also leans heavily on the geniuses at Debian. So, this project stands on the shoulders of giants. In other words, DSL 2024 is a humble little project!
Though it may seem comparably ridiculous that 700MB is small in 2024 when DSL was 50MB in 2002, I’ve done a lot of hunting to find small footprint applications, and I had to do some tricks to get a workable desktop into the 700MB limit. To get the size down the ISO currently reduced full language support for German, English, French, Spanish, Portuguese and Brazilian Portuguese (de_DE, en_AU, en_GB, en_US, es_ES, fr_FR, es_ES, pt_PT, & pt_BR ). I had to strip the source codes, many man pages, and documentation out. I do provide a download script that will restore all the missing files, and so far, it seems to be working well.
> Though it may seem comparably ridiculous that 700MB is small in 2024 when DSL was 50MB in 2002...
It really depends on what you are looking at. This is a bit of an apples to oranges comparison, but OpenWrt happily works with 16MB of disk space, and can go down to 8MB if you squeeze it. It includes a modern Linux kernel, shell, networking stack, ssh server, package manager, text editor, web server with dynamic pages, etc...
Part of it's trick is that it aggressively pares down the hardware support, such that you normally download an OpenWrt image customized to your exact router. But of course the biggest difference is that it doesn't include a graphics stack or any GUI applications.
I work in embedded Linux, and its a whole different world here of trimming the fat on Linux to keep the BOM prices low. But you'd be surprised how lean we can get it.
> There is 264KB of space left for your newly created files.
This could be increased noticeably by using one of the common extended floppy formats. The 21-sectors-per-track format used by MS¹ for Windows 95's floppy distribution was widely supported enough by drives (and found to be reliable enough on standard disks) that they considered it safe for mass use, and gave 1680KB instead of the 1440Kb offered by the standard 18-sector layout. The standard floppy formatting tools for Linux support creating such layouts.
--------
[1] There was some suggestion² that MS invented the extended floppy format, they were sometimes called “windows format”, but it³ had been used elsewhere for some time before MS used them for Windows and Office.
[2] I'm not sure if this came from MS themselves, or was invented by the tech press.
[3] and even further extended formats, including 1720KByte by squeezing in two extra tracks as well as more data per track which IIRC was used for OS/2 install floppies.
41 comments
[ 4.7 ms ] story [ 76.6 ms ] threadAh, good times ;-)
I don't know if that's also true for data integrity on physical magnetic media. FAT12 is not a journaling filesystem. On a modern drive, a crash during a write is at best, annoying while on a 3.5" floppy with a 33mhz CPU, a write operation blocks for a perceptible amount of time. If the user hits the power switch or the kernel panics while the heads are moving or the FAT is updating, that disk is gone. The article mentions sync, but sync on a floppy drive is an agonizingly slow operation that users might interrupt.
Given the 253KiB free space constraint, I wonder if a better approach would be treating the free space as a raw block device or a tiny appended partition using a log-structured filesystem designed for slow media (like a stripped down JFFS2 or something), though that might require too many kernel modules.
Has anyone out there experimented with appending a tar archive to the end of the initramfs image inplace for persistence, rather than mounting the raw FAT filesystem? It might be safer to serialize writes only on shutdown, would love more thoughts on this.
The two main problems I ran into were 1) software support at the application layer, and 2) video driver support. There is a herculean effort on the part of package maintainers to build software for distros, and no one has been building 32 bit version of software for years, even if it is possible to build from source. There is only a very limited set of software you can use, even CLI software because so many things are built with 64 bit dependencies. Secondly, old video card drivers are being dropped from the kernel. This means all you have is basic VGA "safe-mode" level support, which isn't even fast enough to play an MPEG2. My final try was to install Debian 5, which was period correct and had support for my hardware, but the live CDs of the the time were not hybrid so the ISO could not boot from USB. I didn't have a burner so I finally gave up.
So I think these types of projects are fun for a proof of concept, but unfortunately are never going to give life to old computers.
It can boot from a floppy or from a CD drive, and it lets you chainload into a live usb even on old computers.
I used it to boot from CD from a floppy in an old Pentium MMX and it worked great (although slow, of course)
Little known fact; before 2006 all we did was play Pong and make beep-boop noises on our computers.
This statement must be Linux-only
Pre-compiled packages for i386 are still available for all versions of NetBSD including the current one
I still compile software for i386 from pkgsrc
https://ftp.netbsd.org/pub/pkgsrc/current/
NB. I'm not interested in graphical software, I prefer VGA textmode
Start with a conventional MBR and active FAT32 partition, and make sure it will boot to MS-DOS, this only requires the 3 DOS OS files to be present when the bootsector is a DOS bootsector (which seeks IO.SYS).
Once that's done, then (optionally) copy the DOS bootsector to a file on that FAT32 volume, name the (512 byte) file BOOTSECT.DOS. A disk editor can do this, or carefully use dd in Linux.
I then boot to Windows and use its CLI to run SYSLINUX.EXE (v6.03 on virgin media), to "Syslinux" (verb) the FAT32 volume. You can alternatively do this from Linux. This replaces the DOS bootsector with a Syslinux bootsector that will seek a Syslinux folder instead of seeking IO.SYS. Also writes ldlinux.sys and ldlinux.c32 to the FAT volume.
You do have to be consistent with your Syslinux version, the .C32 files in use must be from the same version of Syslinux that you use to "Syslinux" the FAT volume. And must match the version of Isolinux used to make the ISO. To find out which version of Isolinux was originally used on the ISO, open the ISO in a disk editor and these have big sectors but about the third sector down will be some readable text with the Isolinux version number.
Then copy all the files & folders from the mounted ISO to the FAT volume, change the name of the isolinux folder to syslinux, in the syslinux folder change the name of isolinux.cfg to syslinux.cfg.
A properly prepared distro distributed in ISO form should then boot normally the way it is intended when stored on a FAT filesystem instead.
Show-stoppers can still arise when some live distros have .CFG bootstrings within their Isolinux folder that specify CDROM or other hardcoded deficiencies, for USB you can sometimes specify REMOVABLE after you change the foldername to Syslinux. You can also specify a chosen volume in case it's not picked up by default.
You may need to look at every .CFG file in the Syslinux folder, they are all usually linked, ideally there is only syslinux.cfg but some people make it more complicated than that. Back them up before editing but they are just text files.
oh god
And they used to fail all the time, especially when you had something that spanned more than a single disk.
Are you from South Africa? I understand it was the standard slang name there -- and nowhere else, because of the double entendre.
https://www.zelow.no/floppyfw/
to setup small router on 486 with 12 MB ram and run flawless. Later i get Linksys WRT54GL and decommissioned that machine.
As an alternative, isn't ext2 smaller by having no FAT tables?
From the main page:
As with most things in the GNU/Linux community, this project continues to stand on the shoulders of giants. I am just one guy without a CS degree, so for now, this project is based on antiX 23 i386. AntiX is a fantastic distribution that I think shares much of the same spirit as the original DSL project. AntiX shares pedigree with MEPIS and also leans heavily on the geniuses at Debian. So, this project stands on the shoulders of giants. In other words, DSL 2024 is a humble little project!
Though it may seem comparably ridiculous that 700MB is small in 2024 when DSL was 50MB in 2002, I’ve done a lot of hunting to find small footprint applications, and I had to do some tricks to get a workable desktop into the 700MB limit. To get the size down the ISO currently reduced full language support for German, English, French, Spanish, Portuguese and Brazilian Portuguese (de_DE, en_AU, en_GB, en_US, es_ES, fr_FR, es_ES, pt_PT, & pt_BR ). I had to strip the source codes, many man pages, and documentation out. I do provide a download script that will restore all the missing files, and so far, it seems to be working well.
https://www.damnsmalllinux.org/
It really depends on what you are looking at. This is a bit of an apples to oranges comparison, but OpenWrt happily works with 16MB of disk space, and can go down to 8MB if you squeeze it. It includes a modern Linux kernel, shell, networking stack, ssh server, package manager, text editor, web server with dynamic pages, etc...
Part of it's trick is that it aggressively pares down the hardware support, such that you normally download an OpenWrt image customized to your exact router. But of course the biggest difference is that it doesn't include a graphics stack or any GUI applications.
I work in embedded Linux, and its a whole different world here of trimming the fat on Linux to keep the BOM prices low. But you'd be surprised how lean we can get it.
This could be increased noticeably by using one of the common extended floppy formats. The 21-sectors-per-track format used by MS¹ for Windows 95's floppy distribution was widely supported enough by drives (and found to be reliable enough on standard disks) that they considered it safe for mass use, and gave 1680KB instead of the 1440Kb offered by the standard 18-sector layout. The standard floppy formatting tools for Linux support creating such layouts.
--------
[1] There was some suggestion² that MS invented the extended floppy format, they were sometimes called “windows format”, but it³ had been used elsewhere for some time before MS used them for Windows and Office.
[2] I'm not sure if this came from MS themselves, or was invented by the tech press.
[3] and even further extended formats, including 1720KByte by squeezing in two extra tracks as well as more data per track which IIRC was used for OS/2 install floppies.