It was mind blowing at the time because Linux required at least 4-5 floppies to set up a text-only base system while QNX ran live from just a single 1.44MB.
Photon microGUI was included in that, and it blew my mind that you could literally kill and restart Photon without disturbing any of the GUI apps that were still running.
They also mailed a manual along with the demo disk, and I was amazed that QNX had built-in network bonding, amongst lots of other neat features. At the the time I was using Slackware & the linux kernel version was still 1.x, I don't think bonding came to linux until 2.x?
that's not really true. In 2001 I built a single disk linux installation (with a handful of popular nics supported) with X (tiny X with vesafb support) and rdesktop + vnc as a thin client on floppy.
I'd be honest and say that qnx demo disk had more usability overall than my disk, but one could easily have a usable text only linux bootable disk. Busybox and uclibc already existed back then.
You’re missing my point. QNX live floppy came out in 1997. My experience with Slackware 3.x at the time was exactly like how I said it was. You needed two floppies just to boot up the kernel (they were called boot disk and root disk), so Linux setup could start.
I wasn’t claiming Linux couldn’t achieve this, merely stating why QNX was mind blowing: because it was way ahead of what was available, not what was possible.
yes, I was using Linux back then too :). Linux could do it in 1997 as well. I seem to recall (but we are talking 30 years ago so memory might be faulty) of Debian having a 1 disk install for its first release of 1.1 (and pre-releases of 0.x) if one was installing it over a network. by definition then this 1 disk was a fully working linux system on a single floppy.
my conceptual floppy was less to demonstrate it fitting on a floppy (that was just the carrot), the idea was to show how one could dynamically "rewrite" shared libs to only include the symbols one needed to run the apps and have them work.
argument being, static linking a single binary is smaller than dynamically linking it and including the shared library, but as one adds binaries, the duplicated code will eliminate that size advantage. But shared libraries (especially something like glibc) are large and apps dont always use vast sections of them), so what if one could iterate over all the dynamically linked apps one wanted to include and only include the sections of the shared libs that were needed.
So the project was demonstrating that. In practice, uclibc was smaller than the sliced up glibc (and at least for this project, worked just fine)
No Linux distro ran a live/usable system from a single floppy at the time. Netbooting obviously isn't an example of a self-contained usable live system. uclibc and Busybox you were referring to had come out years after QNX live floppy.
