First, I think this is a great idea, and I second your idea!
But, there's sort of a larger problem at stake here with operating systems, and that is the "archaeological WHY".
You see, the way Operating Systems classes are typically taught at university is that you are given an already working, already functional Operating System, which might be as "simple" (a term I use loosely, because it's relative) as Minix. (Minix is not simple compared to DOS, DOS is not simple compared to CP/M, etc.)
But the thing is, while you learn about the different parts of an already functional (multi-functional, because it has many functions) Operating System, you never really learn about the WHY, the reason why, the problem why all of that functionality, all of those systems and subsystems, were established in the first place.
In other words, let's say I have a computer with no OS. Bare metal. And I want the simplest piece of functionality to make my life a little bit easier, like let's say, a simple file system, the ability to run a C compiler, and the ability to use simple commands like "ls", "dir", etc.
Now, that ignores all sorts of other functionality, such as threads, multitasking, locks, IPC, sockets, memory management, GUI, etc., etc.
But, it would allow a greater understanding of the "archaeological WHY".
Once that understanding is firmly solidified, we could explore the next problem on our road to creating a modern, more complex OS. The WHY of that next problem, and the solution to it (increasing in complexity, but building commensurate understanding!) at every step.
>You never really learn about the WHY, the reason why,
This isn't just in Operating System, or Programming but Computer Technology in general. Unlike other Engineering courses from AeroSpace to Mechanical Engineering, which explains everything from basic theory to practice and how we evolve to current design and current ( likely slightly outdated ) industry practice.
...which seems to imply that you're going to need a more efficient language than "traditional" C/C++ if you want to fit more functionality on a single floppy, although given that early UNIX was written in C/Asm, I wonder how much of it is due to bloat/unnecessary/extra abstraction than the choice of language itself.
QNX 4 was mostly written in C and the demo disk fit on a single floppy and included the whole system including a TCP/IP stack, drivers for a few common network adapters, a GUI, a web browser (with javascript), and various demo applications.
Granted, I think it's probably easier to limit size (and more importantly, complexity) by using assembly language, it's by no means necessary. Lately I've been exploring minimizing complexity by using less-capable text editors like ed and notepad.
If folks want to experiment with a tiny, bare-bones unix-y OS on relatively modern platforms, xv6 (used as a teaching OS at MIT) is ~10kloc of C for the kernel and a handful of userland programs: https://github.com/mit-pdos/xv6-public
A few years back I did a quick port of it to x86-64 as a project to learn more about 64bit intel (having been in the ARM world for some time) which was fun: https://github.com/swetland/xv6
These are about twenty years old (Linux 2.2 and FreeBSD 3). While they almost certainly still work on modern hardware thanks to the backwards compatibility of the PC platform, can it be done with newer software?
OpenWrt run's on 4mb flash / 32mb memory devices. If you disable IPv6 / Wireless drivers and tune some more knobs you get probably something that boots a recent 4.14 kernel / musl / busybox from a 3mb squashfs and runs in 16mb memory.
Strongly trimmed linux kernel + minimal userspace based on klibc will certainly fit on 1.44MB. The dash (x86) built with klibc occupies something with <50kB in memory, below 100kB on disk.
That 5MB figure doesn't include the kernel. Usually when people refer to Alpine being only 5MB they're talking about running it inside of a container/chroot.
Ah yes and LOAF - Linux on a floppy. The web site doesn’t exist anymore but it was the first Linux I played with in 1999 because my father wouldn’t let me install Red Hat Linux 5.1 on his hard drive. So I was force to boot off a floppy every time.
One interesting thing was that he wants it to be modern but fit on a floppy disk. Modern computers support USB storage which of course is orders of magnitude faster and larger than floppy disks.
A possible alternative: pester Blackberry with requests for opening the 32bit variant of QNX (crowfunding?), since they're likely moving to 64bit anyway. Very small devices with RAM sizes well below the Gigabyte are the ones which would benefit the most from it.
The ever elusive QNX. I remember being given a boot floppy of QNX for PC, it had a graphics environment, a shell and a web browser. On one floppy. Stable like Linux, small, graphical and fast like Amiga (actually smaller!) and could run circles around Windows 95 on off the shelf hardware.
That would surely make it super fast and super tiny, but sadly also super non portable to different architectures like ARM and very hard to maintain or even develop for.
to be honest writing x86 assembly is Not That Bad™ (personally I can't speak for ARM though)
I wrote some simple silly applications for KolibriOS[0] a while back and it's relatively pleasant (I think a basic GUI window is less code than a Win32 application in C…)
This has prompted me to look if floppies are even still available for purchase -they are (as are USB floppy drives). Also pretty expensive, at 1.5 euros apiece.
You'll compile a lot out, sure, but I don't understand from the discussion why it can't be done. I understand why it's hard, why certain people have no interest in it, and why using a 64-bit address space is important for security defense. But nome of that seems to make it fundamentally impossible.
Depends on how you balance take advantage of modern hardware with be somewhat useful for hobbyist desktop users.
If you think “somewhat useful for hobbyist desktop users” means booting from UEFI, supporting USB-3 including hot-plugging, and doing power management well on generic hardware, I don’t think there’s any chance to stuff everything on a floppy disk.
If you’re willing to remove device enumeration, effectively building a different kernel for each choice of to be supported hardware, work with just a tty over a serial port, and be forgiving a lot on the “Unix-like”, it’s quite doable (example: http://lng.sourceforge.net/, a ‘Unix-like’ OS for the Commodore 64). The “somewhat useful” would suffer, though, and one could argue that isn’t “Unix-like”.
There may be something in-between that adds enough usefulness to make it “somewhat useful”.
I'm always in favor of homebuilt OS projects, I've worked on several in-house OSs and they seem to have good ideas salted around them.
If it were me, I'd write an open source RTOS (yet another one) and cast around for clever notions to stick in the thing, for the mental exercise if nothing else. Perhaps carve out a niche in quality/safety and not so much in performance.
What I partially would love to see is a Unix like OS for the Pi thats designed and built specifically to take full advantage of everything the Pi has to offer. The Pi especially with the Pi Zero is a great tool to learn and teach. Since the Pi Zero is so cheap if it breaks you buy a new one...
Compared to an x86 OS that is specialized and fits in a few MB worth of storate media. I think a custom OS for the Pi could be very lightweight and efficient. Especially given how spread out the SBC is. I am sure there could be a stripped down Distro for the Pi as well. Its a shame that Slitaz is kind of dead.
dragonfly is a full system. 'light' by modern (read: ubuntu, windows 10) standards (e.g. GUI, other things are addons), but a base install will run you about 800MBish
"take advantage of modern hardware, (2) fit on a single floppy disk" that's kinda funny using the works modern hardware and floppy disk together. Tell me where you would even buy a floppy disk or a floppy disk drive.
I grew with floppy disk (5.25 inches) and, yeah, it's perfectly normal (and fortunate) and the people have forgotten them.
AFAIAC, I have fond memories of them : the sound of the drives (anybody remembers Locksmith, CopyII+,... ?), the hope that the copy you made would work (those floppies were not that reliable), my first experience in cracking, etc.
But, there's sort of a larger problem at stake here with operating systems, and that is the "archaeological WHY".
You see, the way Operating Systems classes are typically taught at university is that you are given an already working, already functional Operating System, which might be as "simple" (a term I use loosely, because it's relative) as Minix. (Minix is not simple compared to DOS, DOS is not simple compared to CP/M, etc.)
But the thing is, while you learn about the different parts of an already functional (multi-functional, because it has many functions) Operating System, you never really learn about the WHY, the reason why, the problem why all of that functionality, all of those systems and subsystems, were established in the first place.
In other words, let's say I have a computer with no OS. Bare metal. And I want the simplest piece of functionality to make my life a little bit easier, like let's say, a simple file system, the ability to run a C compiler, and the ability to use simple commands like "ls", "dir", etc.
Now, that ignores all sorts of other functionality, such as threads, multitasking, locks, IPC, sockets, memory management, GUI, etc., etc.
But, it would allow a greater understanding of the "archaeological WHY".
Once that understanding is firmly solidified, we could explore the next problem on our road to creating a modern, more complex OS. The WHY of that next problem, and the solution to it (increasing in complexity, but building commensurate understanding!) at every step.
OK, I'm rambling!
But I like your idea and greatly endorse it!