1. 27
  1.  

  2. 13

    Don’t forget that performance enhancements, security enhancements, and increased hardware support all add to the size over what was done a long time ago with some UNIX or Linux. There’s cruft and necessary additions that appeared over time. I’m actually curious what a minimalist OS would look like if it had all the necessary or useful stuff. I especially curious if it would still fit on a floppy.

    If not security or UNIX, my baseline for projects like this is MenuetOS. The UNIX alternative should try to match up in features, performance, and size.

    1. 13

      We already have a pretty minimalist OS with good security, and very little cruft: OpenBSD.

      1. 7

        The base set alone is over 100mbyte, though. That’s a lot more than OP wants.

        1. 5

          Can you fit it with a desktop experience on a floppy like MenuetOS or QNX Demo Disc? If not, it’s not as minimal as we’re talking about. I am curious how minimal OpenBSD could get while still usable for various things, though.

        2. 12

          Modern PC OS needs ACPI script interpreter, so it can’t be particularly small or simple. ACPI is a monstrosity.

          1. 2

            Re: enhancements, I’m thinking Nanix would be more single-purpose, like muLinux, as a desktop OS that rarely (or never) runs untrusted code (incl. JS) and supports only hardware that would be useful for that purpose, just what’s needed for a CLI.

            Given that Linux 2.0.36 (as used in muLinux), a very functional UNIX-like kernel, fit with plenty of room to spare on a floppy, I think it would be feasible to write a kernel with no focus on backwards hardware or software compatibility to take up the same amount of space.

            1. 3

              Your OS or native apps won’t load files that were on the Internet or hackable systems at some point? Or purely personal use with only outgoing data? Otherwise, it could be hit with some attacks. Many come through things like documents, media files, etc. I can imagine scenarios where that isn’t a concern. What’s your use cases?

              1. 5

                To be honest, my use cases are summed up in the following sentence:

                it might be a nice learning exercise to get a minimal UNIX-like kernel going and a sliver of a userspace

                But you’re right, there could be attacks. I just don’t see something like Nanix being in a place where security is of utmost importance, just a toy hobbyist OS.

                1. 4

                  If that’s the use, then I hope you have a blast building it. :)

                  1. 3

                    It pretty much sounds like what Linus said back then, though, so who knows? ;)

              2. 2

                Linux 2.0 didn’t have ACPI support. I doubt it will even run on modern hardware.

                1. 2

                  It seems to work, just booted the ISO (admittedly not the floppy, don’t have what is needed to make a virtual image right now) of muLinux in Hyper-V and it seems to work fine, even having 0% CPU usage on idle according to Hyper-V.

                  1. 2

                    Running in a VM is not the same as running on hardware.

            2. 11

              Although I’m sure that many people have a desire to have an OS this small, I don’t think that coming to it from the point of file size itself is very practical. Deciding on a floppy for the mechanism to require for max file size seems a bit off, since I don’t think I’ve used a floppy in nearly 20 years. Do people still use them?

              1. 3

                Yeah, we need new metrics. Maybe the cheapest x86 CPU, flash chip, and single stick of RAM. Maybe an energy-efficient, embedded board like the VIA Artigo’s I used to like. Perhaps something like PCEngines that people are already using. I’m not sure but it should be more relevant minimum.

                1. 1

                  I think driving the metrics off of a 2GB SD card and a raspberry pi may be reasonable at this point as well. X86 isn’t driving everything as super much as before :)

                  1. 2

                    A RaspPi is a neat idea for metric. People are doing a lot with them. Which RaspPi though?

                    1. 2

                      I would say the Raspberry Pi Zero since it’s the least expensive and therefore most widely adoptable, but I’m honestly not sure what the best metric would be for deciding on this. :)

                      Note: The zero is 11 GBP (just under $15) and 1Ghz/512MB, and I made this decision because I think that an OS should support people with as low income as possible. (https://thepihut.com/products/raspberry-pi-zero)

                      1. 2

                        One of my early boxes was a 200+MHz PII with 64MB of RAM. That ran Windows 98 with video games, WinAMP, Visual Studio 6, and so on. Although Intel’s chips are highly-optimized, the spec difference indicates a solution for the Zero might be in that ballpark somewhere. At least something like MenuetOS. One list I found just showed a bunch of Linux remixes so far. They look nice but that tells me there’s opportunities for more efficiency, education-oriented, or other design choices.

              2. 8

                I like small things. Heck, I work on keyboard firmware that has to fit into 32k, including the boot loader. But a tiny UNIX-like OS for desktop use is, I think, a bit pointless. As an experiment, a learning tool - yeah, that can work. But then you’re pretty much limited to VMs or a very, very tiny subset of existing hardware. Neither of them is all that useful past the learning stage. Besides, modern hardware typically requires more kernel code, so not focusing on old hardware, and only targeting the modern, you won’t be saving all that much. The other way around would yield smaller results.

                Mind you, there’ve been UNIX ports to 8-bit AVR, which is even smaller than a floppy disk. But it’s a tad limited, and kind of ancient.

                With that in mind, I’d suggest targeting something else than x86/x86_64. Something smaller, like AVR, or a 16-bit MCU. They’re more specialized, require less code to support, and so on. Sounds like a way more interesting project than targeting the desktop.

                1. 8

                  a.out binaries are smaller than elf binaries, so let’s statically link everything into one big executable ala busybox.

                  Similarly, a modular kernel with all its modules takes up more total space than a single kernel with everything built in. So don’t even bother implementing modules. Linux 1.2 was the last great Linux before they ruined everything with modules.

                  64-bit code takes up more space than 32-bit, so let’s build for 32-bit instruction sets. Who has more than 4GB of addressable memory anyway?

                  Optimized code usually takes up more space, often a lot more when inlining is enabled. Let’s build everything with -Os so we can fit more binaries on our floppies.

                  Icons are really superfluous anyway, but maybe we’ll want X11R5 or some other GUI on a second floppy. (I’d say X11R6 but all those extensions take up too much space). Make sure to use an 8-bit storage format with a common palette – 24-bit or 32-bit formats are wasteful.

                  (I lament the bloated nature of the modern OS as much as the next Oregon Trail Generation hacker, but really – is “fits on a 1.7MB floppy really the right metric? Surely we can at least afford to buy 2.88MB drives now?)

                  1. 5

                    64-bit code takes up more space than 32-bit, so let’s build for 32-bit instruction sets. Who has more than 4GB of addressable memory anyway?

                    Most programs don’t need more than 4GB of addressable memory, and those that do, know it. Knuth flamed about this some, but while you can use X32 to get the big registers and little memory, it’s not very popular because people don’t care much about making fast things.

                    I lament the bloated nature of the modern OS as much as the next Oregon Trail Generation hacker, but really – is “fits on a 1.7MB floppy really the right metric? Surely we can at least afford to buy 2.88MB drives now?

                    No, but smaller is better. If you can fit inside L1, you’ll find around 1000x speed increase simply because you’re not waiting for memory (or with clever programming: you can stream it).

                    There was a time when people did gui workstations in 128kb. How fast would that be today?

                    1. 2

                      Most programs don’t need more than 4GB of addressable memory, and those that do, know it.

                      All the integer overflows with values under 64-bits suggests otherwise. I know most programmers aren’t doing checks on every operation either. I prefer 64-bit partly to cut down on them. Ideally, I’d have an automated tool to convert programs to use it by default where performance or whatever allowed.

                      “No, but smaller is better. If you can fit inside L1, you’ll find around 1000x speed increase simply because you’re not waiting for memory”

                      Dave Long and I agreed on 32-64KB in a bootstrapping discussion for that very reason. Making that the maximum on apps kept them in the fastest cache even on lots of older hardware. Another was targeting initial loaders to tiny, cheap ROM (esp to save space for updates). Those were only memory metrics we could find that really mattered in general case. The rest were highly situation-specific.

                      1. 1

                        Most programs don’t need more than 4GB of addressable memory, and those that do, know it.

                        All the integer overflows with values under 64-bits suggests otherwise.

                        How?

                        I know most programmers aren’t doing checks on every operation either. I prefer 64-bit partly to cut down on them. Ideally, I’d have an automated tool to convert programs to use it by default where performance or whatever allowed.

                        What does that mean?

                        1. 0

                          My point isn’t about the addressable memory: it’s about even being able to represent a number. Programs are usually designed with assumption that the arithmetic they do will work like real-world arithmetic on integers. In machine arithmetic, incrementing a number past a certain value will lead to an overflow. That can cause apps to misbehave. Another variation is a number coming from storage with many bits goes to one with fewer bits which caller didn’t know had fewer bits. That caused the Ariane 5 explosion.

                          Overflows happen more often with 8-16-bit fields since their range is so small. They can happen to 32-bit values in long running systems or those with math pushing numbers up fast. They either won’t happen or will take a lot longer with 64-bit values. I doubt most programmers are looking for overflows throughout their 32-bit applications. So, I’d rather just default on 64-bit for a bit of extra, safety margin. That’s all I was saying.

                    2. 1

                      Linux 1.2 was the last great Linux before they ruined everything with modules.

                      https://twitter.com/1990sLinuxUser :P

                      1. 2

                        Why has systemd deprecated support for /usr on a different filesystem!!

                        That issue bit me last month! I moved my /usr because it was too large, and the damned system couldn’t even boot into an init=/bin/sh shell! It dropped me into an initrd shell. I had to boot off a live CD to fix it. (If the initrd shell should have been sufficient, pardon me. I tried, but lvm wasn’t working.)

                    3. 7

                      I think USB drives are cheap enough and floppies relatively expensive, so the value of targeting floppies feels weird.

                      There is the exercise gain of building a kernel, of course.

                      What would be interesting is a combination of modern hardware and oldschool demoscene demos that you boot into. A standardized kernel and set of libraries that you code your demo against without using existing engines.

                      I don’t that will happen and hardware support pretty much requires Linux, but it would be interesting!

                      1. 6

                        Would anybody be interested in using this for anything? I probably won’t ever work on it, but it might be a nice learning exercise to get a minimal UNIX-like kernel going and a sliver of a userspace.

                        I also have some ideas that other people could work on in their free time instead of me. I don’t have the timestamp that points to the quote, but “if all you have are ideas, you’re an ideas guy” from Programming is terrible comes to mind.

                        1. 3

                          Fixed the wording there, I wasn’t saying someone else should go out and make it, just that it’s an idea that I might go ahead with on spare time.

                          Also, this post came out of me working on this idea. I spent about a day working on a similar system, Linux-based, and failed to get it close to my size goal. So I decided to throw this out there to see what people think, if I should spend any time working on it, and if there are any glaring issues (which there seem to be).

                        2. 6

                          (1) take advantage of modern hardware, (2) fit on a single floppy disk

                          So a floppy disk is modern hardware? wut?

                          1. 1

                            Came here to comment on exactly that cognitive dissonance. Any mylar medium is antiquated.

                            Maybe CD-ROM? That’s pretty outdated, too.

                            SD card? Even they’re almost 20 years old, and the smallest spec still handles up to 2GB.

                            Don’t get me wrong – shave all the bits you want (though as others have pointed out, it sounds like he’d rather other people do the shaving for him). I just have a hard time, seeing that contrast, that the author has thought this through to any degree.

                            1. 2

                              Fitting on a floppy disk is different from being distributed on a floppy disk (which is different from needing to be distributed on a floppy disk – a situation that a lot of hobby OSes with homebrewed bootloaders suffer from!)

                              Fitting on a floppy disk is a nice, solid benchmark for size – one that’s still used for Lua & other projects, even when those projects don’t get distributed that way. Right now, fitting on a floppy means being smaller than the average (popularity-weighted) web page, and also means fitting on any commonly-used and many uncommonly-used modern storage media. It also implies suitability (at least in size) for embedded contexts (which may make use of modern features while still having less RAM than you might naturally expect a microwave or elevator controller to ship with).

                              1. 1

                                Fitting on a floppy disk is a nice, solid benchmark for size

                                How big is a floppy disk? 1.44MB, right? Or 800kB, depending on the era. Or maybe 113.75kB, the capacity of a one-sided 5 1/4” disk under Apple DOS?

                                No? It’s 1.722MB? Where the hell did that come from?

                                It is not a solid benchmark. It’s an arbitrary one.

                                I listed a few other, more recent media one could benchmark against, instead. Even those are arbitrary – SD cards range from 1MB to 2GB. CD ROMs vary from 600ish to 900ish MB (much narrower than the SD range, but still variable).

                                Basically, if you have a size in mind, there’s a physical medium that you can claim to be the benchmark.

                                make use of modern features while still having less RAM

                                On-disk size and RAM usage are, at best, loosely correlated. Plenty of small programs will intentionally use lots of RAM, and there are large programs which need minimal RAM. There are other ways to provide a standard for embedded devices.

                                1. 4

                                  1.722MB is Amiga. The Amiga hardware read an entire track at a time, so sectors were done purely in software. This meant you could use a bit more of the disk than on IBMs.

                                  I do recall using Tom’s Root Boot Disk back in the day. It was enough of a usable Linux system to use for rescue work. I’ve even used it to install Linux on a seriously constrained system.

                                  1. 2

                                    How big is a floppy disk?

                                    Generally speaking, when people say “it fits on a floppy disk” they’re talking about a 1.44MB diskette. (It’s a commonly-understood claim, and one that fits with the era in which it first became popular, which is to say the late 90s.)

                                    If you want to go out of your way to bother somebody, you can rules-lawyer them about single-density 5.25 inch floppies or the weird micro-diskettes that the Zenith MinisPort used or other variations. It just requires ignoring a general understanding in favor of being technically correct in the most irritating way possible.

                                    Making a full-featured OS that fits in two megs is challenging enough to be interesting but hardly impossible. It’s also still desirable. The way that such a project would normally be described is “fits on a floppy disk” – even if it doesn’t quite. That description is still understood, even if a lot of us haven’t had a machine with a floppy drive in five or ten years.

                                    I listed a few other, more recent media one could benchmark against, instead. Even those are arbitrary – SD cards range from 1MB to 2GB. CD ROMs vary from 600ish to 900ish MB (much narrower than the SD range, but still variable).

                                    Making an OS fit in 600MB isn’t really much of a challenge. You can get a modern linux distro on a business card CD and still load it with shovelware – no coding required.

                                    On-disk size and RAM usage are, at best, loosely correlated. Plenty of small programs will intentionally use lots of RAM, and there are large programs which need minimal RAM.

                                    Sure. But, a monolithic kernel without modules generally gets its entire bulk dropped into memory. If you make the object code smaller (without demoscene-style compression techniques), the object code’s in-memory footprint will roughly match what’s on disk. That gives you more space for userland to play with, even on constrained systems.

                                  2. 1

                                    It seems like an arbitrary benchmark for size tbh. I would have gone for something like “readable from flash in a time shorter than humans can perceive”,

                                    1. 1

                                      “Fits on a floppy” is the kind of description I heard a lot, when I was in the hobby OS community. Granted, that was about ten years ago, but floppy drives had already been basically totally supplanted by multi-gigabyte flash already by that point. I think people still gravitate toward that benchmark as ‘natural’ in a way that they don’t toward “1.5 megs” or “2 megs”.

                                      (Plus, has tech REALLY moved that much in the past 10 years? Sure doesn’t feel like it. We’re doing the same stuff only slower.)

                                  3. 1

                                    Maybe CD-ROM? That’s pretty outdated, too.

                                    I still use those heavily. I’ve even had some boxes that still performed well but didn’t boot from USB. Doing a CD is still easier than network boot. Just pop that sucker in there, do something else while it slow loads, and begin working with the dialogs.

                                    1. 2

                                      I use them, too. And they’re more durable than magnetic media, which is why I don’t have any Apple II floppies any more, but I still have a FreeBSD 4.0 CD-ROM set.

                                      But they’re still a bit outdated.

                                2. 6

                                  xv6?

                                  1. 6

                                    Also Sortix.

                                  2. 5

                                    There are tiny modern unixes for microcontrollers (LiteBSD, RetroBSD).

                                    For desktops, you can’t “take advantage of modern hardware” when you fit on a floppy. You need to take advantage of SMP (and even NUMA) processors, ACPI, GPUs, 10GbE NICs, NVMe SSDs… and not floppy drives.

                                    1. 1

                                      Couldn’t you target qemu/vmware/virtualbox virtual devices and save yourself all the trouble, if hardware support is a concern?

                                      1. 1

                                        What’s the point of a “minimalist Unix for enthusiast desktop” if you’re not going to run it on metal? Doesn’t the presence of a hypervisor ruin the whole minimal feel?

                                    2. 3

                                      Reminds me of an old saying: “Bloat” is any feature I don’t use right now.

                                      It’s impossible to say something is “bloated” based only on its size. You don’t know why all of that code is there, and you don’t know if there are smaller ways to solve all the same problems. (Stated differently, if you do know there are smaller ways to solve all the same problems, propose them to the Linux people.) And it’s dishonest to cut things out of the problem in the name of cutting them out of the solution: If your project doesn’t solve all the same problems, it’s meaningless to compare it to something which does. It would be like saying a Nissan is bloated compared to a go-kart.

                                      1. 4

                                        If you want the smallest binary possible, you’ll have to cut out a lot of abstractions (libc? dynamic linking? nobody needs that!), employ tricks like these, make use of programming styles that are unorthodox even for assembly programmimng, and use specialised packers and unpackers (like this one, this one, this one, …).

                                        Of course, the project maintainers will call you nuts and not accept your patches.

                                        Besides, the extra size (and worse performance, etc. etc.) doesn’t always happen because of adding features, but rather because of (I think unnecessary) abstraction layers piled on top of one another, mostly things that can be done at compile-time. Here’s an essay describing a thought experiment making it a little more clear.

                                        1. 3

                                          I don’t think any of those tricks should be necessary for targetting a 1.5 meg base system. After all, 1.5 meg base systems were extremely common twenty-five years ago, produced by regular C compilers from regular C code by people who weren’t making any particular effort to trim them down.

                                          You can do incredible things in 4k if you employ those tricks. But, 4k is the size of a completely empty file on unix!

                                      2. 2

                                        The author’s tendency toward minimalism is essentially aesthetic. Yes, there could be security benefits in using a smaller codebase, but they might be negated by not using standard tools with lots of eyeballs and many years of development. While I see the aesthetic niceity of a cute, small, minimal system, I don’t see people really needing floppy-disk sized systems these days. People only have so many resources to throw around and minimizing binary size is rarely worth it.

                                        1. 2

                                          Author here. Yep! It is essentially aesthetic, and there is no real need for it. I will definitely admit to that.

                                        2. 1

                                          This idea seems similar to axel, Minoca, and Sortix.