Looking close at memory usage

Working with 16Mb of physical memory has underscored the importance of two things: first, lightweight applications, and second, keeping a close eye on what is taking up space.

System monitors such as htop are useful for the second point, although using a monitor to watch memory use defeats the purpose to a small degree; it does, after all, take up space. For a shorter, quicker peek, this little script does a great job. Here’s what the output looks like:

 Private  +   Shared  =  RAM used	Program 

  0.0 KiB +  10.0 KiB =  10.0 KiB	dhcpcd
  0.0 KiB +  11.5 KiB =  11.5 KiB	agetty
  0.0 KiB +  12.0 KiB =  12.0 KiB	udevd
  0.0 KiB +  12.5 KiB =  12.5 KiB	startx
  0.0 KiB +  22.5 KiB =  22.5 KiB	xinit
  0.0 KiB +  37.0 KiB =  37.0 KiB	hnb
  0.0 KiB +  42.0 KiB =  42.0 KiB	mc
  0.0 KiB +  49.0 KiB =  49.0 KiB	vim (2)
  0.0 KiB +  49.5 KiB =  49.5 KiB	musca
  0.0 KiB +  50.5 KiB =  50.5 KiB	charm
 40.0 KiB +  11.5 KiB =  51.5 KiB	init
 96.0 KiB +  43.0 KiB = 139.0 KiB	tty-clock
240.0 KiB +  68.5 KiB = 308.5 KiB	htop
312.0 KiB +  41.5 KiB = 353.5 KiB	alpine
500.0 KiB + 243.0 KiB = 743.0 KiB	bash (4)
736.0 KiB +  51.0 KiB = 787.0 KiB	centerim
768.0 KiB +  77.0 KiB = 845.0 KiB	urxvtd
996.0 KiB +  49.0 KiB =   1.0 MiB	Xorg
---------------------------------
                          4.5 MiB
=================================

 Private  +   Shared  =  RAM used	Program 

I find that interesting mostly because it helps answer a long-standing question, of how it all fits. But it also puts a few things into perspective, like the fact that Musca takes up less space than tty-clock, or that htop and alpine are standing on the same amount of ground, more or less.

On a bigger system the results might be a little more intersting. And now I can take a more critical approach to lightweight versus heavyweight software, with some numbers to back myself up.

P.S.: Thanks to LinuxPlanet for pointing it out.

Six months without X

I had to check back against the calendar, but if my calculations are right, it’s been about six months since I tossed X overboard on my Thinkpad. I won’t bore you with a bunch of anti-X rantings because I have spewed forth plenty of anti-X rantings in the past.

And because it would be slightly hypocritical, in a technical way. For as much as I run X-less, I also rely on X (albeit a year-old version) to keep this Pentium afloat. Sure, it can run without it — all the applications are the same. But because the hardware predates the VESA requirements in recent kernels, there’s not much fun to be had with the framebuffer.

But that too is old news, really. Xorg 7.3 is a great substitute for the lack of framebuffer support here, but given the choice on a machine this old, I’d definitely drop it like a hot rock.

And why? Mostly because it returns a large slice of your system resources to you — although that argument is a bit weak, considering I’m talking about a Pentium with 16Mb in it.

But also because everything moves quicker, snappier and just plain faster without X as an intermediary layer. I’ve discovered quite a few things that make things faster over the past few years, but the best results seem to come from taking things out. And X is one of those.

I promised not to rant, and it seems already I did. If you haven’t tried life without X I recommend it, just for a little while. I can’t predict with any certainty that you’ll get hooked, but if you’re one of the lucky ones, life will certainly get better.

Eclipsed, obsoleted, retired

For the past few days I have debated disassembling the original Pentium laptop I got as a throwaway from a coworker about a year ago. I agonized over it a lot more than I probably should have, particularly considering it’s relative value, or lack thereof.

I had two reasons for doing it. The first I mentally categorized as an act of mercy — the power switch was unreliable and potentially dangerous. Disassembling it gave me the opportunity to look at it, although I knew beforehand that I was unlikely to be able to do anything about it.

The other reason was a little bit greedy: I was holding out hope that the core 16Mb of memory could be removed and transplanted into the newer Pentium. I have enough experience with decade-old equipment to know that a lot of these mid-to-late 1990s model laptops had a brace of memory that was fused to the motherboard, and not transplantable.

And this one was true to the rule. Any hopes I had of pulling a buried memory stick out of it and using it the other machine were instantly quashed when I got the (massive) heat plate out from under the keyboard. No stick. Just a farm of four or six Samsung chips, near where the battery sat.

And a cursory look at the power switch told me no more than what I already knew — that it didn’t seem to be working. I considered taking it apart piece by piece, but I doubt my own ability to effect any improvement, so the effort involved seemed wasted from the outset.

So now I am debating whether it is worth reassembling it and keeping it as a leftover machine, or as a backup for parts for the newer one. My instinct says no, that the sketchy performance and less-than-perfect condition make it unlikely to be truly useful any longer.

So I stacked it, disassembled, on a shelf until I convince myself to finally part with it. Funny, even just six months ago, this was my primary machine for everything — and I mean everything — I did on a daily basis. But once the new machine showed up, I began to see the faults in the old one, and realized it wasn’t really what I wanted after all.

Isn’t that the way life works, though?

Using dmenu with xft fonts

I mentioned dmenu in the last post, and I should add that I find it quite useful. Going back all the way to gmrun, and perhaps even to those quirky little command line widgets for the Gnome desktop, or maybe even GnomeDo (if I understand it correctly), everybody loves typing a few letters and getting the program they want.

See? You secretly love the command line. Admit it.

My only disappointment with dmenu was that it refused to show any xft fonts for me, as it was installed in both Crux and Arch. No matter what I did, or which system I was using, I kept getting the awful core X fonts in the dmenu bar.

Perhaps I was doing something wrong, but apparently there was no configuration file that handles dmenu’s behavior, and that all of its few options are triggered when it is spawned. I have no problem with that, except that I was awaiting the crucial information — is it possible to use xft fonts at all — before recompiling Musca to trigger dmenu, and hopefully make it work.

Arch came to my rescue again, this time in the form of an AUR package that pulls in a patch to allow dmenu to show those fonts. Colin Zheng’s conversion script did the work and within minutes, I could show dmenu with the Terminus font on my Pentium.

Again, I might have gone about this in completely the wrong way — I have a reputation for finding solutions that are far out of date, or worse, completely unnecessary. But in this case, a quick patch and a cross-compilation, and I don’t have to look at that awful X font any more. All in the name of science, of course.

Reducing memory use with urxvtd and urxvtc

Interesting, but by way of dmenu, I discovered something I wish I had known a long time ago: That there is a daemon available to rxvt-unicode, which will allow you to run multiple terminal instances with a slimmer memory footprint and quicker spawning times.

I have always resented the fact that my terminal-based systems running under X incur a rather hefty price in the way of one instance of urxvt per application, which in turn implies one instance of bash per application. (One of these days I’ll get off my rear end and pick a shell that isn’t quite as hefty, relatively speaking, as bash. Suggestions welcomed. )

I had been using dmenu in Musca to start applications with urxvt -e (application), and each time I saw options for both urxvtd and urxvtc. A quick skim through some man pages, and now I understand that urxvtd is the daemon, and urxvtc triggers the daemon to spawn a new terminal window.

Which means that instead of four terminal emulators taking up a wide slice of the 16Mb I have in this Pentium, I have one daemon running and four applications hooked into it.

Why bother? Well for me, as I have already implied, the amount of space required is suddenly a fraction, inversely proportional to the number of emulators you originally needed. (That makes almost no sense at all, but suffice to say that when I ran tty-clock, centerim and hnb alongside charm, I used to need four terminals and four instances of bash to run them. Now I need only one daemon, which I suppose suggests it takes up one-quarter of the resources. … )

Now that we have settled the why, here’s the how: On an ultralight system or any system that relies on .xsession or .xinitrc (which suggests Openbox, et al.), insert this line to the .xinitrc file.

urxvtd -q -o -f

The q flag spares you the startup notification. The o flag picks the open X display and the f flag forks the daemon and takes it out of your way.

Now, whenever you spawn a terminal window, use urxvtc instead of urxvt, and the running daemon will hand you another terminal prompt.

There is a downside to this (there always is, isn’t there?): If the daemon dies, all the applications hooked to it can suffer the same fate.

For me, running that risk is worth it, for two reasons. First, this machine has so little memory to spare, that the 1 or 2 megabytes I save by eliminating the one-emulator-per-application is significant.

Second, the time it takes to open a new prompt is likewise reduced. I recompiled Musca to link the urxvtc command to the Mod4+t key, and now the daemon sprouts a new prompt in a fraction of the time it used to swap out the memory and start a whole new emulator.

I realize this is hardly news, and it’s hardly interesting to anyone who’s not using terminal applications as a matter of course. I probably wouldn’t even bother using this on my Openbox systems just because I don’t use enough terminal applications on those to warrant setting it up.

On the other hand, if you’re a bottom-feeder like me, you will claim back a sliver of memory and a smidgin of start time by relying on the daemon, instead of one emulator per application.

Noteworthy Linux console fonts

I spend most of my time working at the console, with an array of text-based programs running against the framebuffer. The default console font is acceptable, but can be kind of clunky, particularly when a finer grain of font would be preferable.

A clean installation of Arch Linux (or Crux Linux, because for what I can tell there’s not much difference in the font selection between the two) has a few more interesting fonts available, but it’s a little difficult to tell which ones are which. As far as I can tell there is no gallery of Linux terminal fonts anywhere; if you know of one, please tell.

In Arch, fonts are located at /usr/share/kbd/consolefonts, although sometimes a package installs a font in an unusual or isolated place. The bulk of what you see there is probably a specific character set for an individual language or alphabet.

On the other hand, some are not. Here are six or seven that are a little more interesting. This is displayed against a 1600×1200 framebuffer, so it may be that the particular size you want will require a resolution that your hardware might not support. You can set and display a font with these commands:

setfont (name-of-font-here)
showconsolefont

Cybercafe

A strong contrast to the run-of-the-mill default font. It has a very techno feel, but tends to push letters together in some places, which might make it tough to read.

cybercafe.fnt.gz

972

I don’t know what else to call it but that; it’s obviously intended for a specific alphabet set, but it stands out mostly because the letter shapes are quite different from normal. I am not sure if those scrambled characters are corrupted, or intended.

972.cp.gz

Terminus

The almighty Terminus font, shown here as Lat2-Terminus. This is probably my favorite, but I admit when I want it I install a package that gives me a 12-point version.

Lat2-Terminus16.psfu.gz

Greek Polytonic

Interesting in that it opens up a lot of “white space” (black space?) between lines, and has a character set that seems more blocked and less rounded in most places.

greek-polytonic.psfu.gz

9×16 Medieval

Way out of the ordinary, this is a font with real flavor. Readability is only so-so, but if you throw this into your NetHack session, you’ll dig it.

gr737b-9×16-medieval.psfu.gz

Sun 12×22

A 12×22 font is enormous on one hand, but on the other, it’s probably the cleanest and sharpest on a high-resolution screen. You’ll lose a little screen space to this one, but you’ll be quite happy with the clarity. Good for typing or editing over long periods of time; bad for paneling and splitting up a console window … because suddenly there’s no space.

sun12x22.psfu.gz

t

A scriptlike font, a little less upright and a little more relaxed. Like some of the others, this is a little smeared at times, but much more casual than the default series. What do you call it? t.

t.fnt.gz

That’s all I have today. Keep in mind that these are fonts for the console, and won’t necessarily work in a terminal emulator in a graphical desktop. Chances are though, there’s a rendition of it somewhere that will work with X.

P.S.: Ubuntu users, you’ll have to skim through your console fonts yourself. A lot looked different in there, when I looked last.

Ubuntu with 256Mb … not so smart

Clonezilla makes things too easy for me, really. Being able to snap between installations in a matter of minutes takes all the challenge out of the two or three hours — or two or three days, depending on the distribution — of reinstalling a system.

In the days since that memory chip failed, I put Ubuntu back on the Inspiron. I don’t know why I was surprised, but the performance fell off considerably between now and when that chip was (semi-)working.

No shock there, really. With only half the memory available, Ubuntu suddenly began swapping for the least of program startups. Gnome Text Editor? Grind, grind, grind. Starting up Firefox? Grind, grind, grind. Showing icons in the drop-down menus? Grind, grind, grind.

Well, maybe not that last one. But the system monitor confirms it: Even after a cold power-up, memory usage sits at 160Mb, and anything beyond full idle suddenly drags in even more. I’m sure every system is different, but for me, that’s what I have to live with.

But I shouldn’t complain; Gnome is not my domain, and I am only a cursory visitor therein. Complaining because someone else decides to run their system differently from what I suggest is somewhat rude — like inviting yourself over for dinner, and then complaining that the food is too salty.

Still, it’s hard for me to compare that to my Thinkpad, which is running ten applications at the same time, one of them being a ripped DVD out of my collection, and using only 37Mb of memory.

Or against this new laptop, the Pentium, which is admittedly swapping out 21Mb of space, but consuming only another 6Mb on top of that. And that’s with Xorg 7.3 and four instances of bash all making it happen.

In the mean time, I’ll keep waiting for my new memory chip to arrive. And probably switching out this installation within the next few hours, to avoid the lag. Thank goodness for Clonezilla.

Musca and e3, with space left over

Now that I have X up and running on the new/old laptop, I have shifted gears slightly, and installed two of my own suggestions: Musca and e3. You can see Musca running in this screenshot, but e3 is not there; that’s because it really doesn’t look much more different than vim (the version I prefer, that is).

I do believe I may like Musca better than Awesome, or at least Awesome 2.3.4, and at least on this hardware. The memory usage is much smaller, which is a good thing.

But it also feels a lot more intuitive, even just from the default. I like that you move between windows with combinations of the modifier key and the arrows — that I find easier to manage than the j-and-k style that Awesome used. And for some strange reason I like the separation between the bracket for the application, and the application itself.

But probably another reason I like it is because I use screen so much, and movement between and around split screens in screen is completely un-intuitive. If screen allowed you to stretch and slide viewports like Musca does, I’d never use anything else.

If you decide to try it just to get a quick taste, dmenu isn’t really necessary, although it does make some things easier. I find I don’t use it so much, and Musca works just as simply for me without that additional application. There’s also a great tutorial here, and a quick reference page for commands here.

I don’t have a precise number for the memory footprint for Musca, but I see in some htop windows that it’s using about 3.3 percent of the available memory, which means about 400kb, if my calculations are correct.

e3, on the other hand, requires even less, and while it’s a darned good editor, I won’t be supplanting vim with it so long as word wrapping remains an issue. For normal editing, like configuaration files and whatnot, it’s fine, but I prefer vim’s wrapping setting if I can get it.

And vim isn’t so chunky that I can’t get things done with it. It opens quite quickly, although it’s being swapped from the drive most of the time.

In any case if you’re putting together a system that is so light and thin as to be transparent, I would highly recommend either of those. Between the two you’re talking about maybe 1 or 2Mb as system requirements, which means you’ll have gobs of space available for anything else you decide to install. Even if it only has 16Mb to start with.

Quake Live at 1Ghz, 256Mb

I had been waiting for Tuesday, just out of morbid curiosity. But my bizarre desire to be disappointed will go unfulfilled this time. Here’s Quake Live on the Inspiron, running with half the memory I usually have after one chip went schizo.

That’s Crux, by the way. I expected laggy performance and skipping graphics. But framerates are exceptionally good, although I didn’t find a way to show a number on screen. I’m not a huge first-person shooter fan, but it’s fun to try out.

Crux and Awesome at 120Mhz, 16Mb

Finally, after several false starts and a couple of botched attempts, a fully 800×600 graphical desktop in 16-bit color depth, with Awesome 2.3.4 as the window manager using Crux 2.4 with Xorg 7.3 on a 120Mhz Pentium with only 16Mb of memory.

No tricks, no smoke or mirrors, no fancy footwork, unless you call building the entire thing from scratch “fancy.” The biggest stumbling blocks were getting X to run at all, and getting a network card to play nice with the hardware. For some reason, all the network cards I have — with the exception of my trusty WPC11 and maybe the ASIX-based wired card — trigger messages from the kernel claiming “cardbus cards are not supported.”

Right now the plan is to use the WPC11 until I can get the system into a condition I like. Performance is about the same level as the 100Mhz machine was … in other words, a 20Mhz difference does not offer a magical improvement in usability.

But hey, usability is all a matter of perspective.