Is Ubuntu really going low-spec?

by Rudd-O published 2007/01/12 22:44:30 GMT+0, last modified 2013-06-26T03:24:18+00:00

We all want to run Linux on 64 MB of RAM. But Ubuntu Lite's way is not the right one.

:: Reviews : Ubuntu Goes Low Spec! (found here) introduced me to the new project called Ubuntu Lite.

What's Ubuntu Lite? It's a new Linux distribution. Its goal is to make a usable Linux-based system that works on 128 MB of RAM. How they plan to achieve this goal seems straightforward: around "lightweight" applications.

And it's is exactly the wrong way to build a low-footprint distribution. Why?

Saving pennies, squandering dollars

First, the applications and building blocks chosen are simpler. In other words, they have less functionality than the two standard behemoths: KDE and GNOME.

Say it out loud: they're building a cripple from the outset. It will never be as functional as any environment that comes with either KDE or GNOME.

Does that lead to a low memory footprint?

Second, the project is motivated by an underlying assumption: using simpler, heterogenous applications yields less memory usage.

This assumption is wrong. A recent study by Lubos Lunak completely disproved it. Chief findings of the study:

  1. the system with heterogeneous applications (Xubuntu, promoted as the 'lightweight' variant of Ubuntu) did boot up into less memory usage;
  2. but, as soon as any useful applications were opened, Xubuntu lost the war against both KDE and GNOME

There's a perfectly reasonable explanation to this: both GNOME and (to a larger extent) KDE share much more code than the heterogeneous applications in Xubuntu. More shared code equals a larger footprint without open applications, but an incrementally appreciable benefit when real users are actually using the machines. Especially, if I may remind you, in terminal services settings.

Low-hanging fruit

Sure. I know one type of low-hanging fruit. Compile every application and library using the gcc -Os flag. It makes smaller binaries, which are faster to read from disk, and take (a bit) less memory. The savings should add up to about 10-20 MB of RAM, according to my completely unscientific estimates.

There's another. Disable functionality (by properly configuring the applications before compilation). I'm not sure this is the route to take.

After that, any gains become exponentially harder.

Into the future

Fortunately, all is not despair. After the study was completed, it underwent wide distribution on the Internet. That study was directly responsible for cementing the belief on shared code.

Today, both KDE and GNOME are more committed than ever on the agenda of sharing code, and optimizing this very shared code can yield significant benefits. There are big gains lurking in all that shared code, and it's yours for the taking. It's just a matter of applying freely available tools and the scientific method. Instead of squandering time placing decals on your hot rod, why not try some real software tuning?

As for Ubuntu Lite: I just hope the Ubuntu Lite guys realized, independently, what you just read, and surprise us with newer ideas.