So I was telling my dad about how Damn Small Linux weighs in at 700 MB, to which he scoffed and commented on how tiny operating systems used to be in the past, which would make this seem like a colossus in comparison.
So I started wondering: Why don’t we see people making operating systems that are only a handful of kilobytes in size, or smaller? Even if it’s just for the challenge?
Why is the smallest version of Linux available still clocking in at several hundred megabytes? I’m not even assuming a desktop environment or GUI at all. I’m just thinking about a text-only terminal here.
My hypothesis is it’s a combination of the following:
Address widths have gotten larger, so instructions can use more disk space, on average.
Modern operating systems tend to come with self-repair tools, documentation, and multiple available language packs, which is now considered the bare minimum standard for lightweight builds.
UTF-8 is becoming increasingly standard, which has a higher average byte-per-character count.
But I feel like this shouldn’t make a significant enough difference to account for the incredible size increase over time.
So, to anyone more knowledgeable, may I ask how the “lowest possible OS size” became so big over time, and why we don’t see anyone making operating systems smaller than a megabyte anymore?
Your reasons 1 and 3 are a factor of four, max. Not a big deal.
“Bare minimum functionality” is the answer. In 1985 an operating system was some disk management routines and a sticky note saying “Virtual memory sounds like a good idea, maybe we should try it?”
A modern Linux needs a complete set of system administration tools – shells, compilers, scripting languages, what have you. Also enough kernel stuff to deal with every variety of PC that it might be installed on.
Why is the smallest version of Linux available still clocking in at several hundred megabytes? I’m not even assuming a desktop environment or GUI at all. I’m just thinking about a text-only terminal here.
There are smaller ones, notably Tiny Core Linux at 17 MB. It actually manages to have a desktop environment and the X window system.
There are a few others that even small enough to fit on a floppy. As you suspected, these don’t have any desktop environment.
As @zarf noted, the Linux kernel is one limitation. Googling it suggests that it’s about 10 MB uncompressed and 2 MB compressed, so you won’t get a Linux distro much smaller than that.
There are also some non-Linux hobbyist OSes like KolibriOS and MenuetOS, which have a desktop and fit on a floppy. But they don’t do much.
Maybe you were aware of some of these, since you mentioned about one MB as a sort of lower limit.
Oh, there are also some very small bootable disks that serve a single purpose — check out the QEMU advent calendar.
I threw one MB out there as a general ballpark without any data behind it lol.
So my dad looked up the computer he used to use, and apparently OS-9 was designed for a specific CPU, and all the computers which ran OS-9 all had the same CPU, so that’s why he remembers there being so much variety, in addition to such a small OS!
That kernel stuff is quite a lot, it seems! I know when I remove a few old kernel versions from my computer, I get at least one gigabyte back. So in addition to the minimalistic utilities, being specialized for a single CPU seems to help quite a lot, too!
The first Linux distro I used was called Minilinux, a Slackware subset that came in 4 floppy disks, It had X Windows and it took 15 MB from your MS-DOS filesystem (as umsdos didn’t need a partition):
Edit: apparently it was created by a Portuguese ISP. It was pretty amazing.
Compiling your own kernel you can get quite a bit smaller. The kernel has a truly amazing amount of software within it. It also has a very convenient menu system where you can toggle on or off the features you want to build.
And even 10mb is a rather reduced version of the Linux Kernel as the kernel I’m currently running clocks in at 110mb… and is the third largest package installed on my system(the largest is firefox at over 260mb, second is libllvm19 at about 125MB, 4th is firmware-amdgraphics at 91MB, and fifth is gcc-14-x86-64-linux-gnu at about 68MB, and those are all the packages installed on my system that are bigger than 50MB… and I know this thanks to a script I wrote to get the size of every installed package and sort them by size)… And the size of firefox is another clue. Pretty much every modern OS bundles at least one modern web browser and all modern browsers are beefy things, and since I’m talking debian packages, that 260MB figure is just Firefox itself, not counting its dependencies… and in my case, needing a screen reader adds quite a bit(Orca just fits on the last screen of output from my script at about 15mb, but it has many dependencies, and among them, my speech synth(espeak-ng) and the speech server that lets Orca communicate with a variety of speech synths(speech-dispatcher) are both bigger than orca itself… and most modern OSes bundle a screen reader even if its disabled by default… though, skimming the output from my script, I also found core-utils at 18MB in my top 25 largest packages.
If one did a clean install of Debian with the netinst, let it install the base system and then select nothing at the install additional software step, I suspect the resulting system would weigh in at least an order of magnitude smaller than the 2.4GB my current set up takes up on my root partition.
And that’s why Linux blows other modern OSes out of the water for small install footprint: It’s fully modular, you could install just the kernel built specifically for your specific hardware and absolute bare minimum system utils if you wanted, every other major OS gives you no choice but to install all of the bundled software and if they come preinstalled on a new machine/device, you’re likely being force fed whatever the hardware vendor decided to add on to the OS.
On the small distro front, There’s also Damn Small Linux, which googling suggests had its most recent release in 2024, though I suspectits grown from the 10MB it was some 10-15 years ago, especially since the page about the 2024 release mentions the inclusion of Firefox-ESR, suggesting its focus might have shifted from being literally as small as possible to just running on the lowest spec machines possible while still providing a modern computing experience. Also, I’m pretty sure Linux is a popular choice for embedded systems(I understand most routers run Linux if they aren’t running something fully custom), which leave a lot of room to remove things that would be missed on a general purpose PC.
In the 8-bit era, if you were going to use an OS, it had to be loaded from somewhere when you turned on the computer, but personal hard drives aren’t in the picture yet. So there would be a bare bones kernel in the ROM, but on floppy-driven systems, you really thought of the OS as being attached to each floppy.
On the Apple II for instance, you would initialise a new 140kb floppy with the OS you wanted for it. Boot that floppy and you’re in that OS, usually at the BASIC prompt. You could also free up space on a floppy by deleting some code from it and making it not-bootable.
To support an OS that was unlike the Apple’s own offerings (e.g. CPM) and took up more space or needed coprocessors, you would need to buy a CPM hardware card and put it into one of the slots in the computer.
Apart from the relative smallness of everything, the hardware was not changing. Millions of people had the exact same hardware. OSes could rely on memory locations being the same, and knowing exactly what to find and where, so there’s no bloat for catering to variations. The static smallness is why people can know the entirety of an 8-bit machine and recall memory addresses off the top of their head.
I think users of the various BSDen would take issue with that claim. But, per Andrew’s point, those systems have a much more restricted idea of “minimum acceptable functionality” than is typical among Linux distros.
Yeah. I run OpenBSD on routers/firewalls, and just the base install (without any special shoehorning or customizing) fits in a couple hundred MB and does everything you need for a firewall/router. But that’s a completely different animal than trying to run even a basic desktop environment.
Way back when I used to run minix off a single floppy. Minix is still around, but now the min install is listed as being 1 GB. Which I assume just means “less than a gig, but we’ve never bothered to find out precisely how much less because what even has less than a gig these days”. But modern minix has a desktop environemnt, while the version I was running off a floppy was just something that would let me run a terminal emulatior that would let me dial into the machine where I was going to do my actual work.
This made me remember trying to determine the right size for a Windows 7 disk partition back in the day. I first tried with 20 GB, but this left less than one gig free, which was too little for my purposes. So I doubled the partition to 40 GB, but to my surprise this made the Windows 7 installer decide to automatically install more stuff, still leaving me with less than one gig free.
let’s look around here (Debian system): the kernel proper is just shy of 8 Mbyte (Megabyte) but what take space is initrd.img (a readonly disk image used during the boot) with 50 Mb
And, one should keep in mind that Linux installations is often done for programming so that the C compiler and libraries take even more space than the kernel itself, and one must also add also the headers.
Browser’s sizes isn’t bloat, but the enduring consequences of a major design mistake done by Tim Berners-Lee @ CERN (that is, since day 1…) who used a set of NeXT-specific features & routines, sleek on that hardware, but rather cumbersome when ported on other hardware & OS, starting the avalanche which is still rolling down the years and decades. nihil novi sub sole, I daresay…
Later I’ll look at a current DSL live distro image and I look at the weight breakdown of its component (mewtawer, do you think that your script can handle an .ISO image mounted in loop ?)
Best regards from Italy,
dott. Piergiorgio
ps. for the record, I have looked at my /usr/local/bin and with my surprise, if one abstracts from Inform 10, some 'terps binaries are actually much larger than the compiler binaries (the largest compiler binary outside I10 (8,5 Mb) is t3make with 2,9 Mb, above it is frob (3,2 Mbyte), qtads (32M) hugor (31M) and Gargoyle 2023 (52M) )
And I took a look at my script, turns out its one of those single commands you throw into a script because the command is complicated enough and will be used rarely enough you’ll never remember it, but useful enough you don’t want to look it up every time you need it.
Since it uses dpkg-query, it should work on any debian-derived distro, though presumably will ignore anything installed via a method other than apt or invoking dpkg directly with a .deb package. I forget what all the little bits of the command do, but it prints the installed size and name of every installed package in dpkg’s database and pipe them to sort to sort them by increasing size. I believe the -n flag to sort ensures it handles the sorting of the numbers correctly since numbering gets weird with alphanumeric sorting. Do note, the package sizes are displayed in bytes and I have no idea how to get the output to display in terms of kilobytes and megabytes or kibibytes and mebibytes… as far as I know, dpkg-query doesn’t have a equivalent of du’s -h flag for human-readable sizes.
Probably useless on a non-dpkg system or if you have a lot of self-built software, a lot of pip installed python packages, a bunch of snaps and flatpacks, etc.
Don’t use it much myself, but I put it together at a time when doing a clean install took over an hour and it then took days to go from what the newly installed system was to how I wanted it, so I developed a habit of aggressively making my installed system as small as possible to speed up the process of booting into a live system to create and restore back ups of my system drive… Now that I’m on decade newer hardware, have an SSD system drive, and have switched to a distro with a more flexible installer and less unwanted stuff installed by default, a clean install now takes maybe 10 or 15 minutes and my post-installation tweaking takes hours, not days, so less incentive to keep my root partition’s contents small for quick backup and restore.
My first personal computer was an AT&T machine with a massive 20 meg hard drive and 640Kb of memory… it ran MS-DOS… The OS was about 300KB and used about 50Kb of RAM. It was certainly no BSD, but it got the job done as a personal computer in 1985. (Edited to correct hard drive size)
Yeah, 20GB of hard drive is unbelievably huge for a DOS machine. Heck, 20GB was practically unheard of even during the Win9x days and I wouldn’t be surprised if some first gen WinXP machines only had 20 gigs of storage… And I just realized my current desktop has more RAM than my family’s first Windows machine had hard drive… With how much compute a modern machine uses just to surf the web, it’s kind of mind boggling programmers of the 80s where able to do half of what they did with so little compute at their disposal. Guess it just goes to show how much Wirth’s Law trumps Moore’s Law.
The trouble was also elsewhere: the pressure on programmers or coders.
Without entering in the specific of the milieu, the fast-paced tempo stemming from the market competition of the specific industry led to little time given to code optimisation, either in speed and size.
I take my time in coding, often looking if I can get smaller binaries (I recovered more than 200 Kb on adv3Lite binaries simply omitting instruct.t and newbie.t from the .tl (Isekai is definitively NOT an IF for novices, but if I code a much simpler IF, I’ll use the standard .tl) and when I got stuck in coding, either for bugs or codes which don’t work as designed, I light a cigar, sit on an armchair (winter) or walk in my garden (summer) (and 95% of the time, the solution suddenly came in my mind…) but slow-pacing coding can be done in a non-competitive environment.
in the competitive environment, time for niceties like optimisation, and even carefully thinking about the code structure (and even testing and debugging…) isn’t available, so invariably the resulting binaries became bigger and bigger.
on 20 Mbyte HDs, I once has done (successfully !) an experiment with 86box, proving that was feasible a workable (that is, a database, wordprocessor and a spreadsheet, a pair of compilers, under DOS 2.x) a 4,77Mhz 8088 XT with 256K RAM and a 5 (yes, FIVE) Mb hard disk (2,8+ Mb available for data, plus 360K of floppy) but was a stunt for my enjoyment…
When I was in middle school in the mid-2000s, my family was running Windows XP on IIRC a 10 GB hard disk, which was part of a Frankensteined computer made from my uncle’s old PCs.
Since we live in a remote place, we had to specially order that 10 GB HD to a small computer store. We almost certainly overpaid for it. I think we had to do this because the PC needed an IDE HD, but our local stores were only stocking SATA hard drives at that point.
Over a decade we put far more money into the Frankenstein PC than it would have cost to buy a new PC. Though it did teach me how to take apart a PC.
These are very interesting!