Notes on Linux

If we look at the history of Unix we can see that the kernel, libraries and userland programs have all increased in size as time passes. Here is a summary of the sizes of libc.a, the main library for C language:

Unix version 2 from 1972:  31 functions and 5,242 bytes
Unix version 5 from 1974:  85 functions and 21,542 bytes
Unix version 6 from 1975:  74 functions and 22,042 bytes
(note that with v6 the math functions were moved to liba.a)
Unix version 7 from 1979: 154 functions, and 77,690 bytes

2.11BSD from 1992: 347 functions, 233,788 bytes

Slackware Linux 4.0 from 1999: libc.so.5.44 has 580,816 bytes

Vector Linux Classic from 2007: 1,425 functions and 2,979,634 bytes

Similarly we can see that basic commands like ps for process status have also increased in size:

ps for Unix v5:      2,660 bytes
ps for modern linux: 63,948 bytes (a 24-fold increase!)

One could easily wonder "at what point does the feature set of a given part of an operating system reach completion"? It seems we never reach that point. On the other hand we don't necessarily have to continually upgrade our operating systems. We could reach back into the past and pick an older starting point and upgrade that distro as needed.
Over a decade ago I started running a web server based on Fedora Core 1 which still runs to this day. There's no doubt in my mind that FC1, while leaner than the most of the current distros from 2014, is still bloated with tons of functions I never use. In other words the ideal operating system, one in which does exactly what I need and no more, does not exist. I will give an honourable mention to OpenBSD though.

There has been some good work done to counter the bloat. Tiny Core Linux does a reasonably good job of being lean and mean. It isn't what I would call low memory use though, it still needs at least 46 MB of RAM (compare this to Unix v5 which can run easily in 256K of ram).

Others will argue that as the feature set of an operating system increases it is inevitable that its size will also increase. That is true but I can't help wonder exactly why libc.a has to be almost 3 megabytes in size. There has been work done to make a leaner libc with the MUSL project. MUSL libc.a is a mere 1.6 megabytes which is significantly smaller.

What else could one do to improve the ever increasing bloat of their operating systems? Well, you could roll your own software distribution or even write your own operating system. You could pick a distro based which uses the MUSL version of libc, e.g. Snowflake and Sabotage.

Unfortunately even the so called light distros seem bloated to me. The true champion of lightweight distros is Basic Linux 3.5 which is based on Slackware 3.5 from 1999. It can run within 16 megs of memory and it can use Slackware 4.0 packages.  There are still folks that use it on older hardware. Of course we can rule out Firefox or Chrome or most other modern web browsers while constrained with such a severe memory limit, although we can still use text based web browsers like lynx.

Using a truly ancient operating system like Unix v5 would seem too restrictive to all but the most hard-core PDP-11 aficionados. We can safely assume that everybody would want an operating system that supports ethernet and TCP/IP. Also a working PDP-11 is a rarity and they wouldn't be efficient in terms of power use.

It seems to me that bloated operating systems go hand in hand with corporations who want to sell everyone endless updates of software and hardware. Computer users need to make a judgement call on just how often they want to upgrade and how much money they want to spend. I've already reached the point of upgrade fatigue and I'm putting most of my efforts into maintaining and repairing my existing computers. The truth of the matter is chip fabrication pollutes the world with caustic chemicals like Trichloroethylene. The endless production of plastic isn't doing our environment any good either.