Or maybe I misremember... I know my machine at the time got upgraded to 24MB so maybe it was that machine I was running.
Anyway it's neat this can still be done.
A floppy distro (especially one relying on a compressed initrd) will inherently require more memory. And I suspect the maker of this distro is using a different definition of "minimum" than we would have used back in the 90s (closer to "recommended").
However, it looks like modern linux kernels just require more memory; The kernel binary is certainly larger, floppinux is spending an entire 888KB on it's very stripped down modern linux (doesn't even have networking enabled), while older floppy distros using 2.2/2.4 kernels keep it under 512KB (with networking, and a bunch of other features.
Also the goal was to run LATEST kernel with no changes - just config. With other compression algorithms it was impossible to fit everything into a floppy. And I really wanted to have nano and some space to save few files. Without this it would be totally not usable OS.
8MB, at least in an emulator, can run a basic Xterm but not a lot else (though it'll happily run as a remote X frontend for a more powerful machine over Ethernet, it was fun to see it try to render Gimp 3 running on my desktop lol)
My 16MB 486 had no issues with a full IceWM session (this was kind of my hacked version of BasicLinux which itself was built on a ~2000 version of Slackware)
I think 1MB of RAM in a simm was about £100 at that point, but it's been a while!
Edit: Add: 2MB/4MB boot with a stripped down kernel, not generic.
I did all these experiments a year or two ago. I lost most of my work due to a hard drive failure (the one in my workstation, not the 386 lol) but all the surviving work is on my github:
Still apparently available on Sourceforge.net, though last updated in 2013:
Since it had no hard disk, and no monitor, it was quiet, and used little power.
I built it to do network-based disk imaging of fleets of Windows 9X PCs in a K12 school district. I used udpcast[0] to receive the image of a FAT32 volume (as a raw dd of the source drive gzip'd) and would stream it in realtime (decompressing and writing) to the hard disk drive on the clients.
I would run the udpcast sender on a "gold master" PC and stream its drive out to as many clients as I wanted (over 10Base-T Ethernet at the time, but later over faster networks). Since the sending PC's CPU was typically the bottleneck the receiving PCs never had problems falling behind receiving and writing the stream.
The most time consuming part of this "generation" of the tool was writing all zeros to the free space on the "gold master" computer to minimize transferring "slack" space (since I was just using dd and not a filesystem-aware tool). I'd mount up the drive in a Linux distro and dd from /dev/zero to a dummy file on the volume until it was full, then delete the dummy file. (One of Jeff's axioms of computing in play: Never underestimate the power of stupid technology.)
I updated the "distribution" in the early 2000's to support NTFS using the various ntfsprogs tools (ntfsclone, ntfsresize) to support imaging Windows XP machines. It was vastly more efficient than the dd method because it only transferred the used blocks of the filesystem.
Since you could make bootable CDs (and later DVDs) using floppy diskette images as the "boot media" I updated the "distribution" again to support mounting a local optical disk and streaming the image off a bzip2'd ntfsclone image. I even added some silly multi-disk "spanning" capability for images >4.7GB. (It was very janky and involved recombining the image chunks in a temporary partition on the local drive, then imaging the machine from that local copy. The I/O contention of reading / writing from the same drive made that very, very slow.)
Finally, when PXE-capable NICs were more common, I would PXE boot the "distribution" (because PXE easily supported booting floppy disk images) and modified it to pull from HTTP, local optical drive, or udpcast.
I gave up when AHCI became common because I couldn't keep up with making the "modern" Linux kernels work with the various models of PCs I was using. I moved over to a Windows PE-based tool in about 2006 - 2007.
https://micheleandreoli.org/public/Software/mulinux/mu/html/...
When i was 12 or 13 in the very early 2000s i tried to download something called “coyote linux” (from sourceforge iirc) and boot it on an internet cafe pc because i really wanted to try this linux thing.
But i was very nooby and of course it mostly didn’t go anywhere. I have vague memories of maybe getting it to boot, getting a shell and then not know what to do with it.
Fun times :)
It's a shame QNX (desktop) died, used to be way more performant and stable compared to Linux or anything else back in the day.
[1] https://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx....
BrowseX, written mostly in Tcl/Tk, was included in one microdistro. Probably LNX-BBC, per Wikipedia.
<https://wiki.tcl-lang.org/page/BrowseX>
<https://en.wikipedia.org/wiki/Bootable_business_card#Operati...>
I would love to have a modern recreation of it.
The version of the SYSLINUX bootloader that it uses had a bug in the fallback path if E820 memory information is not available from the BIOS, and the BIOS on my machine indeed does not support it, or E801 for that matter[3].
I have not gotten around to further testing and fixing the actual issue in SYSLINUX yet (also one of the RAM sticks has sadly developed a parity issue, so I'm stuck at 16M for now). However, I did manage to dig up a newer 486 machine[4][5]. From some testing just this weekend, the BIOS on that one does support INT 15h, AX=E820. I'll have to dig up more memory, but I'm looking forward to another round of trying to get this to boot on the actual hardware, once again :-)
[1] https://news.ycombinator.com/item?id=46866544
[2] https://news.ycombinator.com/item?id=46873814
[3] https://imgur.com/a/GCG9jO7
The idea is cool but anything nowadays has USB ports, there is no suck solution to run from those devices.
Nice to read all of those comments. The project goal is more to learn how to make your own Linux distribution than to fit as much as possible on a floppy. It is fun to have a fully working OS at the end of this learning experience. Floppies are easy to use and just cool :)
There are a lot of better suited distributions for size and memory usage. What makes FLOPPINUX stand out is the complete tutorial to follow and then make your own changes on top of it. Learn and have fun!
Also, some system tools need FP support (like df).
also I got 486 DX2/66 as my first PC so I set that as a goal. Then checked how lower can I go. Also I only have 486 DX4 now to test on real hardware.