Low-Fat Linux - Now with Less Cruft!
By Ben Okopnik
OK, I admit it - there's no such thing as "Low-Fat Linux" (unless somebody just came out with it in order to spite me.) These days, the average installation is pretty big - and many of the most popular programs take up huge swaths of space. Even with a 60GB hard drive like the one in my laptop, you still have to pay close attention lest it become Godzilla, The Eater Of All Available Space (and time, too - but we're not talking about Quake III or Xbubble at the moment.)
So there you are - going along, innocently doing your work (or playing your games), installing delicious little packages (Yum!) that sound interesting or that your friends recommended... and then, one day, you cast a casual glance at your system, and a slight chill runs down your spine.
ben@Fenrir:~$ df -h Filesystem Size Used Avail Use% Mounted on /dev/hda3 958M 362M 548M 40% / /dev/hda5 33G 25G 6.5G 79% /home /dev/hda1 5.5G 4.8G 521M 91% /home/ben/Music /dev/hda6 13G 12G 389M 97% /usr /dev/hda7 1.9G 699M 1.1G 40% /var /dev/hda8 46M 9.1M 35M 21% /boot tmpfs 253M 4.0K 253M 1% /dev/shm
Yikes! Just look at that '/usr' partition!
And now comes the dreadful awareness that you're going to have to delete something. In fact, given the size of the partition, and the number of megabytes that it takes to make up even one percent of it, you're going to have to delete a lot of that something. How the heck are you supposed to figure out what to delete???
Let the panic begin.
After a few calming exercises - a little yoga, a lot of deep breathing, several gin-and-tonics, etc. - you decide on a rational approach (at least if you didn't go for the gin-and-tonics. Otherwise, you'll be doing it later - and that hangover headache will not be working in your favor.) First, you clean out a few games - the ones you don't play much if at all. However, you quickly discover that the interesting games are all BIG - and the simple, boring ones don't do much to fill the trash bucket with megabytes. Kilobytes, more likely. Run "apt-get clean" to remove the cached installation packages in Debian? Oh, that helped... in the '/var' partition, that is. Not in '/usr', where we need it most desperately.
OK, well... let's give it some thought. Oh yeah... all those installed packages - right. It's going to be quite the long and tedious process, but it does indeed pay off: one of the effects of free software is that many people tend to install things "just to check them out", get distracted, and - well, cruft, like entropy, always increases. It's just a law of physics. However, although we haven't yet found a way to reverse the latter, the former can indeed be done - with a bunch of effort. So, on my Debian laptop, it all looks like this (at least post-cleanup):
# Count installed Debian packages ben@Fenrir:~$ dlocate -l|grep '^ii'|wc -l 2133 ben@Fenrir:~$ dlocate -l|grep '^ii'|less ii 9menu 1.8-1.1 Creates X menus from the shell ii a2ps 4.13b.dfsg.1-1 GNU a2ps - 'Anything to PostScript' converter and pretty-printer ii aalib-bin 1.4p5-25 sample programs using aalib ii aalib1 1.4p5-28 ascii art library - transitional package ii abcde 2.3.99.5-1 A Better CD Encoder ii accesscontrol 1.0-2 control panel that activates handicapped accessibility features ii acpi 0.09-1 displays information on ACPI devices ii acpid 1.0.4-5 Utilities for using ACPI power management ii adduser 3.87 Add and remove users and groups [ the rest of long list elided ]
Over 2,000 packages... well, I could mutter some sort of a justification for most of them, anyway. The ones that I couldn't find a reason to keep went away - configuration and all. That cleared away a significant chunk - but not enough to "grow on". It was similar to giving your house a quick little once-over with a whisk broom and ignoring the dust monsters under the bed, the horrible mess in the attic ("It's not a problem - nobody can see it!"), and the biological experiment that used to be a half a pound of tuna salad in your refrigerator: just fine for a quick visit from your neighbor, but it would all collapse in a second if your snoopy aunt Marge came over. Heck, the stuff in the attic will just collapse onto your head if you let it go a couple more weeks even without Auntie crawling around up there. It really is better to take care of it now, before the ambulances, the embarrassing articles in the local newspaper ("Local Man Buried In His Own Trash: Mother Dies Of Shame"), and your friends' sarcastic laughter. Indeed, Drastic Measures are now called for.
"More drastic measures?", you say, aghast. "What could be more drastic than giving up my programs, installed by the sweat of my brow (even if I have no idea what they do and have never used them in the three years that they've been installed)? What do you want, blood???" Nah, nothing like that; I'm usually happy with fine wine and chocolate. Maybe a side of blood oranges and Rainier cherries, if you really insist.
However, my point is that system cruft accumulates almost invisibly - and costs you little (other than a little study and searching) to remove. If you've had your system installed for any significant length of time, and have done a lot of updates, there are a number of programs which don't remove their previous versions before installation - notably, programming languages. I'm a big fan of Perl, and have been installing every new version of it, as well as many of its modules, as long as I've been using Linux. Chances are that you, too - given how many programs on the average Linux systems require Perl - have done the same thing. Ditto Python. Ditto the GCC compiler. Ditto your favorite language - or perhaps some language that you've never even heard of but is necessary for compiling your favorite applications. In other words, you need to take a second, differently-informed look at that package listing: even if you don't know much about programming, you can still spot multiple installed versions of languages. Of course, if trying to uninstall one produces a message warning you of current dependencies, and you want to keep all the programs that depend on that specific version of a language, then you need to hold on to it - but usually, the latest version is enough. If you're careful, and know what you're doing, you can look at, e.g., the '/usr/{share,lib}/{perl,python,ruby}*' and '/usr/local/{share,lib}/{perl,python,ruby}*' directories and see which ones are redundant - or perhaps can become so if you reinstall the modules in the newest versions of those languages. I found, for example, that removing the old Perl, Python, and Ruby versions from those locations freed up several hundred megabytes - at no cost beyond reinstalling a few packages. Admittedly, this did take some time and careful querying of the package database.
OK, now that we're on the hunt - what's next? Well, one of the traditional ways to chomp arbitrary but huge amounts of space on your machine - not that this is specifically Linux-related - has always been the installation of fonts. Great Ghu knows why we need so many: after all, despite our best imagination, few of us are actually graphic designers. Most of us, though, end up installing lots and lots of them... and then sneaking in a few more, just to be sure. Many ([cough] several hundred) of these can all be some indistinguishably-similar version of Arial or Times New Roman or Tekton - but, hey, who knows? We just might feel like this one instead of that one someday, and then what would we do if it wasn't there?...
"Off", cried the Red Queen, "with their heads!" And rightly so. At least if they're unnecessary fonts.
ben@Fenrir:~$ xlsfonts|wc -l 18673
Oh, dear. That is just way, way too many fonts. Sure, I like them as much as anyone else... but really. If I estimate - generously - the number of fonts that I actually use, explicitly and by name, I might come up with a dozen. OK, two dozen. If I want to get really fancy with an OpenOffice document while making up a business brochure, I might like to have a field of, say, fifty or a hundred to look at... but over eighteen thousand? I think not.
# Count the number of available fonts ben@Fenrir:~$ apt-cache search xfonts|egrep -c '^xfonts|^ttf' 86 # Check which ones are installed on my system ben@Fenrir:~$ dlocate -l |grep '^ii xfonts' ii xfonts-100dpi 1.0.0-2 100 dpi fonts for X ii xfonts-75dpi 1.0.0-2 100 dpi fonts for X ii xfonts-a12k12 1-8 12-dot Kanji & ASCII fonts for X ii xfonts-artwiz 1.3-5 x11 fonts created by Artwiz, TigerT, and Daniel Erat ii xfonts-base 1.0.0-3 standard fonts for X ii xfonts-base-transcoded 6.9.0.dfsg.1-6 standard fonts for X (transcoded from ISO 10646-1) ii xfonts-bolkhov-cp1251-75dp 1.1.20001007-6 75 dpi CP1251 encoded Cyrillic fonts for X (Cyr-RFX collection) ii xfonts-bolkhov-cp1251-misc 1.1.20001007-6 Character-cell CP1251 encoded Cyrillic fonts for X (Cyr-RFX collection) ii xfonts-bolkhov-koi8r-75dpi 1.1.20001007-6 75 dpi KOI8-R encoded Cyrillic fonts for X (Cyr-RFX collection) ii xfonts-bolkhov-koi8r-misc 1.1.20001007-6 Character-cell KOI8-R encoded Cyrillic fonts for X (Cyr-RFX collection) ii xfonts-bolkhov-koi8u-75dpi 1.1.20001007-6 75 dpi KOI8-U encoded Cyrillic fonts for X (Cyr-RFX collection) ii xfonts-bolkhov-koi8u-misc 1.1.20001007-6 Character-cell KOI8-U encoded Cyrillic fonts for X (Cyr-RFX collection) ii xfonts-cronyx-cp1251-100dp 2.3.8-6 100 dpi CP1251 encoded Cyrillic fonts for X (Cronyx collection) ii xfonts-cronyx-cp1251-75dpi 2.3.8-6 75 dpi CP1251 encoded Cyrillic fonts for X (Cronyx collection) ii xfonts-cronyx-cp1251-misc 2.3.8-6 Character-cell CP1251 encoded Cyrillic fonts for X (Cronyx collection) ii xfonts-cronyx-koi8r-100dpi 2.3.8-6 100 dpi KOI8-R encoded Cyrillic fonts for X (Cronyx collection) ii xfonts-cronyx-koi8r-75dpi 2.3.8-6 75 dpi KOI8-R encoded Cyrillic fonts for X (Cronyx collection) ii xfonts-cronyx-koi8r-misc 2.3.8-6 Character-cell KOI8-R encoded Cyrillic fonts for X (Cronyx collection) [ Actual complete list snipped in embarassment ]
Well, lots of them, anyway.
A careful review and removal of these - paying attention to the dependency warnings, of course - helped quite a lot, another couple of hundred megabytes or so. What helped even more was a careful examination of the actual font directories - it turns out that X.org (as contrasted against XFree86) decided to rationalize their font structure by combining it with the traditional system location for fonts, '/usr/share/fonts' instead of the old '/usr/X11R6/lib/X11/fonts'. However, the old font directory was still there - and still packed with a hundred-plus MB worth of files! A careful comparison of what was there (in fact, I backed up the entire directory temporarily to see if there were any bad effects) with the new '/usr/share/fonts/X11' structure helped recover a huge bunch of space. I did end up keeping quite a lot more than a hundred fonts, by the way - I depend on Unicode fonts for quite a lot of my work, and I need a good selection of Russian and Japanese fonts in addition to the base font package that comes with X - but at this point, I'm down to a much more reasonable 5000+ fonts (around 3000 unique ones), including all the TrueType fonts that I like.
A quick digression into details may be useful here: I suggest taking a good look at Thomas Adam's "How Fonts Interact with the X Server and X Clients" article to gain a bit of understanding of how fonts work. Taking him at his word ("...font servers: you don't need them."), I carefully checked all my font directories for the presence of "fonts.alias", "fonts.dir", and, in the case of TrueType fonts, "fonts.scale" files - all easily created with the help of the 'ttmkfdir' and 'mkfontdir' utilities. I then confirmed that all my font directories were listed in my '/etc/X11/xorg.conf', in the "Files" section, and - Voila! - I had all my fonts available without running the 'xfs' or 'xfstt' servers, or having 'unix/:7100' or 'unix/:7101' (the server ports) listed in that section or in the 'xset q' report. Not that those servers took up a huge amount of space, but X now seems to start a bit faster than it used to, at least in my perception.
So, was all that worth it? You might say so.
ben@Fenrir:~$ df -h Filesystem Size Used Avail Use% Mounted on /dev/hda3 958M 362M 548M 40% / /dev/hda5 33G 25G 6.5G 79% /home /dev/hda1 5.5G 4.8G 521M 91% /home/ben/Music /dev/hda6 13G 9.9G 2.3G 82% /usr /dev/hda7 1.9G 700M 1.1G 40% /var /dev/hda8 46M 9.1M 35M 21% /boot tmpfs 253M 4.0K 253M 1% /dev/shm
Sure, that took a couple of hours of work - but at this point, I know the state of my system, I've got a couple of gigabytes worth of space in '/usr' again, and I'm more aware of what kinds of things eat up space (and what should be checked once in a while.) In my opinion, that's definitely a gain - in knowledge and understanding, as well as in available disk space.
Talkback: Discuss this article with The Answer Gang
Ben is the Editor-in-Chief for Linux Gazette and a member of The Answer Gang.
Ben was born in Moscow, Russia in 1962. He became interested in electricity at the tender age of six, promptly demonstrated it by sticking a fork into a socket and starting a fire, and has been falling down technological mineshafts ever since. He has been working with computers since the Elder Days, when they had to be built by soldering parts onto printed circuit boards and programs had to fit into 4k of memory. He would gladly pay good money to any psychologist who can cure him of the recurrent nightmares.
His subsequent experiences include creating software in nearly a dozen languages, network and database maintenance during the approach of a hurricane, and writing articles for publications ranging from sailing magazines to technological journals. After a seven-year Atlantic/Caribbean cruise under sail and passages up and down the East coast of the US, he is currently anchored in St. Augustine, Florida. He works as a technical instructor for Sun Microsystems and a private Open Source consultant/Web developer. His current set of hobbies includes flying, yoga, martial arts, motorcycles, writing, and Roman history; his Palm Pilot is crammed full of alarms, many of which contain exclamation points.
He has been working with Linux since 1997, and credits it with his complete loss of interest in waging nuclear warfare on parts of the Pacific Northwest.
