K.Mandla's blog of Linux experiences

fbterm on a 150Mhz Pentium MMX, 32Mb

As a short update, I’ve been using the Mebius as my primary machine for the past few days, taking over from the Fujitsu Pentium. I’m using Arch Linux i586 still, having added quite a few things here and there to the “vanilla” setup that comes from a clean installation.

Probably one of the best things I did with this system was to build yaourt from scratch. It does behave a little strangely because of some library inconsistencies, but once it was in place I had a much easier time skimming through AUR and building things from the community repo.

abs is likewise an excellent tool on a system like this, but I mentioned that in the past so I won’t dwell on it again. Thus far I’ve been able to add hnb, a customized version of Charm, screen-vs, wyrd, alpine, fbterm, fbv and a lot of others — most of the ones I have listed here, in fact — with only a few holdouts, and they’re usually not worth mentioning.

fbterm runs great by the way, kicking up the system demands to roughly 25 percent of processor power and less than a third of memory, and that with everything I need running at the same time. It might sound like a lot, but remember this is a 150Mhz Pentium with only 32Mb to start with, so I’m still taking up only around 12Mb or so, plus a small slice of swap.

I have three small complaints though, none of which are particularly tied to any other.

First, this hard drive is so slow that even most day-to-day tasks, like booting or starting up the smear of software I use normally, are suddenly huge impediments. Generally speaking the system isn’t terrifically taxed — I think the CPU usually floats between 33 and 50 percent demand, and I already mentioned where my memory is at. But it’s still taking over two minutes to boot to the login prompt, which I generally don’t tolerate even in outdated hardware.

On the other hand, the good thing about having a 2Gb drive is that it is easy to make backups or system updates — flash the drive across USB1.1 with dd while I am at the office, then dd it to a file on another machine. Or mount that USB drive and chroot into it, and use it like a phony system. Reverse the procedure to put it back. I’ve done that three or four times now without any problems, except for the time it takes, round trip.

That Trident framebuffer I mentioned a day or two ago is no more lovable for being prettier than a straight console. Yes, I get a nifty console now that I can run fbterm against it, but I have more issues that I haven’t mentioned — like the fact that the entire display appears to be wrapped around, left to right, by one pixel width. If that sounds bizarre it’s even weirder to look at: One pixel on the leftmost part of the screen is occluded, missing … while on the right side, at the same level vertically, I can see a faint, single row of pixels that appears to be what’s gone from the left.

Add to that some discrepancies in the way it displays and captures images — I still haven’t gotten a proper framebuffer image from fbgrab or fbshot, for that matter — and it’s turning into a less-than-ideal graphics card. But something tells me it probably always was. …

Running a system with so little memory appears to be causing problems for other software too. For example, I usually transport the system via USB to a host machine with more power, preferring not to waste time off my life by compiling at 150Mhz. However, for the few times when I have built things on the slower computer, xz has spat out an error so esoteric I can’t even seem to find it on the Internet: “memory usage limit is too small for the given filter setup.”

If there’s a setting somewhere or a way to tell xz how to work at a low memory level, I’d love to find it. The man pages don’t seem to mention anything, and surprisingly this time Google doesn’t have much to offer outside of the source code or an obscure, unrelated post to a mailing list from a year or two ago. As it is I still get a compiled product so I can do something drastic, like rsync the results into my root directory, or even just build a program in the conventional configure-make-make install fashion. But it would be nice to get that one, small, last step working right.

I have other reasons for preferring the older Pentium to this newer one, but usually they’re superficial — like the keyboard layout, or the “feel” of a key press (the Mebius needs a little more “force” to depress a key, which I am not used to). In general, much this time as any other time I have downscaled to the hardware of a decade-and-a-half ago, I am surprised and delighted that I can get so much done with such a little footprint. Yes, there are faults in its personality, but I have a feeling I will be keeping this machine for a long time to come. :)

No, I hadn’t heard of that before now. To be honest, I lost track of all the pacman frontends and wrappers a long time ago. But since it comes with the endorsement of elmariachi, I shall definitely try it out. … :mrgreen:

Not to puff myself up, but I’ve also got an AUR frontend that
I’m developing and using called Aurora. I’ve not used Clyde, but I hear it’s rather good. However, if you’re inclined towards small python scripts, please check out aurora at http://www.bitbucket.org/bbenne10/aurora.

That being said, there’s another good AUR frontend called Auryea that a friend of mine developes. Auryea and Aurora are similar in goal (handle nothing that pacman already does – simply allow for searching of AUR, editing of PKGBUILDs and the downloading and management of those packages downloaded from AUR and be faster than yaourt :)) but Auryea is written solely in bash. If I remember correctly, the speed of it isn’t amazing, but it works well and it’s certainly better than yaourt. Find that at http://bitbucket.org/darvid/auryea

Find something else with ‘AUR’ in the name and I’ll likely switch to it. I though AURyea was clever in it’s ambiguity of pronunciation (fwiw, I THINK it’s meant to sound like ‘area’, though I’m not certain)

If you’re planning on using my solution, be aware that aurora currently doesn’t do a bounds check on the entered software index number. For instance, if you enter an index of 100 and there are only 20 results, aurora fails. Other than that though, I know of no bugs (though I’m sure some are there…)

might want to check out green, too.
it’s a framebuffer pdf viewer using SDL as backend, much prettier than fbgs as it uses poppler behind the scenes and much faster as it doesn’t render to file first.
xz usually automatically adjusts the memory usage depending on RAM present. it will use 80% of your ram when <80mb total and automatically adjust compression level and stuff downward to fit that envelope. if it doesn't work then you are simply shit ouf of luck and xz won't work unless you get a big fat swap i guess.