More successful networking purchases

I realized a day ago, that I needed to bring my perspective into line a little bit. For about two years now, maybe more, I’ve been holding on to a somewhat-useful axnet-cs-based wired PCMCIA card, because it was occasionally in a good mood and would connect a really old laptop to the Internet, and sometimes save the day.

Truth be told, its success rate was under 50 percent, but I always assumed it was an issue of configuration, that I could probably rely on it in a pinch, and that it was worth keeping around for compatibility issues.

So imagine my surpise earlier this week, when I bought a second leftover PCMCIA wired LAN adapter, and brought it home and plugged it in, and found that it too used the axnet-cs module, and that it too dropped connections when the traffic spiked. I dug the old one out of the trash, and stashed them both in the closet, for emergencies.

And then I started to think about it: Why stand on ancient PCMCIA cards that I know to be less than useful — and in some cases actually the source of problems — when there are literally bins full of leftover PCMCIA network cards at the recycling store? Why suffer these quirky leftovers when 10-year-old network cards are only about 95 cents US, and sold with a smile?

I can afford to sink a few dollars into finding one that’s not axnet-based, that doesn’t need a dongle and is mostly reliable, I told myself. And while I’m at it, there’s no need to keep the unworthy floppy drive for the 560e in the closet, when there are two or three spare IBM external floppy drives floating around in those same bins, and not one of them is more than US$3.

So I went to the recycling shop yesterday and scrounged around until I had found two cards that I was fairly sure would be CardBus-free and probably work with Linux (of course, with hardware as old as what I seek, it would be terrifically rare to find something incompatible). The first was an IODATA-branded PCET100-CL, which needs no dongle and immediately lit up like a Christmas tree when I stuck it in the 560e. Debian pounced on it, pointed its finger, shrieked “NE2000!” and assigned it to eth1.

The other was a Planex ENW-3503-T, in its original box and with a faded TurboLinux sticker on it (“OK!” says Tux, while holding a lightning bolt). That proved to be a winner too (Tux doesn’t lie) when Debian found the pcnet-cs module for that one, configured it and assigned it to eth2. I’ll probably use the first one though, since the second needs a dongle, and I dislike those.

So there were two cards, both avoiding hardware chipsets (or software drivers, I suppose) that are less than helpful to me, and neither one costing me more than a few US dollars, relatively speaking. Why I never did that a year ago is still a mystery, considering the dozens of times I tossed them aside while digging around in the recycling store.

(I was a little less lucky with a leftover Thinkpad floppy; it powers up and the drive will spin, but it too doesn’t read the floppy, which could mean that it’s not compatible, or maybe not working. I can try again; I saw at least one more while I was there on Friday.)

Wait, though: The best part of the story is coming. When I originally bought the 560e, there were two PCMCIA cards still stuck in the ports. One was some sort of IBM emulator card (I think it was a token ring adapter) and the other was an Intel PRO/100 PCMCIA card. I jumped for joy to see the second one until I remembered there was no dongle, which made it into a worthless hunk of plastic and aluminum.

Making a long story short though, the Planex dongle fits the Intel card, and while the lights don’t turn on while it is running, it gets sustained download speeds of well over 500kbps, and possibly more if I use a fast, in-country server. It feels good to watch a Pentium download an entire Ubuntu ISO — a file that takes up one-third of its hard drive — in less than 18 minutes.

So now I have three working wired network PCMCIA adapters, none of which shows any difficulties and all of which show nice, fast, consistent download speeds. What happens to the old axnet-cs cards? I’m not sure. I don’t like throwing stuff away, but I don’t like pawning off less-than-reliable hardware on someone else. I suppose it’s a buyer-beware situation anyway when you’re working with stuff this old, but if I can convince myself that the lifespan of those cards is expired, I might send them on to the aluminum reclaimers.

I guess the moral of the story here is simply, “When working with out-of-date hardware, there’s no reason to suffer through poor performance.” That might sound odd, but it makes sense if you think about it: There are so many cheap, leftover replacements for certain accessories that unless you’re strapped by virtue of location or function, you can afford to employ a scattergun approach, and buy two or three at a time and take your chances. Provided the hardware still works, it’s fairly safe to say that Linux will too.

detox for troublesome file names

My job occasionally requires that I handle files written and named in international character sets. Sometimes that is inconvenient, not in the least because file names can cause odd behavior at the command line, or interfere with the way files are managed or opened. My worst-case scenario was a file I couldn’t save after I had edited it, because the name of the file was interfering with the application’s ability to write to disk.

Manually renaming a file is the obvious solution, or if there is more than one, a fun little tool called detox will systematically convert nonstandard characters into boring equivalents. In my case, a Japanese file name might be changed from an unreadable sequence to something like “K-U_e_R_yen_ae_yo_o.doc” — which is easier for me to open, edit and send along.

By default detox will handle mundane things like converting spaces (which sometimes annoy me) to underscores, changing unusual character sets with analogues in common keysets, and weeding out characters which otherwise interfere with life at the command line — like certain quote marks or keycodes.

One of the nice things about detox is that it is configurable to a very low level, so if you don’t like the particular conversion it picks on its own, you can adjust it slightly for different results. That also means that specific sequences and character-to-character translations are probably doable.

As it is a command line tool there’s nothing really to show for it in action. The documentation is excellent and it makes a provisions for dry-runs with the -n flag, so you can test it once or twice if you have a fear of committment. There may be other ways to circumvent this issue but as an easy one-step solution to a lesser inconvenience, I find this acceptable.

Five unattached ideas

Occasionally I collect links that I think might make interesting posts, but individually these don’t really constitute enough to ramble about. So here are a few points bundled together, so that they might stand better than they do alone:

1. I learned something the other day, by way of Phrakture’s blog — how to properly supply information for a bug report. I report them when I’m sure they’re bugs and not something freaky I’ve done wrong, but I need to make a note for future refrence because the tips and guidelines there seem wise. Once more, the Arch Linux Wiki proves why it’s one of the best around.
2. So long as we’re mentioning blogs, I’ll make another plug for Luke Maciak’s Terminally Incoherent, which is a nicely written collection of technological discussions ranging from gaming to TV to popular culture. I don’t have a submission for the call for “best IT stories,” although I do have a truly classic anecdote about the tech staff at my last job, who didn’t know how to fix a Fedora Core 4 server because it had never broken in the three years it had been running, and ended up asking me if it was possible to do some things for them. …
3. Ubuntu GUI users have a club of their own, and it seems to me that there ought to be a CLI club too. Membership will be loose and casual, anyone who uses operating system that has a command-line prompt is allowed to join. No dues, aside from an occasional screenshot to entertain other club members. I submit:

   

   There will be punch and pie.

4. About a month ago I made a note to myself of a page that showed some helpful terminal commands. Some of them are useful, others are rather mundane, and still others are now tattooed on the back of my left hand, so I can read them as I type. There are a bijillion sites around these Internets that show wicked ways to use the command prompt, the best of which are command line fu and Command-line Kung Fu. I should’ve used the word “fu” in the title of this blog, but at the time I didn’t realize its popularity with Linux geeks.
5. Finally, there is a sad irony in the pursuit of computers that are silent — or at least computers that are less than noisy. As I mentioned in that thread, I have a perfectly soundless machine … the only problem is, nobody wanted to talk about my 120Mhz Pentium laptop but me. Still, to think that 14 years ago we had quiet computers, and now you actually have to buy specific parts to dampen the noise … what’s the word for that? Oh, yes: regression. Or at least, it is to me.

Now go forth, and be kind to one another.

Console news, feed and e-mail readers

Feed readers, news readers and e-mail clients all represent a hazy gray area for me, since many of them do two or even three of those things at the same time. So for fun, I have a lump of applications here that might do one of those things, two of them, or maybe all at once. Regardless, they don’t burden your system with garbage, and that’s the real point.

I’m not going to mention alpine or mutt, mostly because mutt is the Internet poster child for console mail readers (meaning you’ve probably already heard about it, and your best friend’s sister’s boyfriend’s brother’s girlfriend has it set up with GMail), and because alpine is something I talk about here. I’ve also mentioned elmo in the past, but because I see no updates on that front, there’s nothing more to say that hasn’t already been said.

First, two important alternatives to alpine and mutt: cone and sup.

 

cone is convenient and quick, menu-driven and most options are easy to control and figure out. Compared to something like alpine, which is overpacked with options and settings, cone is almost kid’s play to set up. How well you go along with cone (as with anything I mention here) is going to depend a lot on your mail service and hardware, so I won’t bore you with cumbersome details about configuration.

Personally, I think I might prefer sup though, mostly because it seems more streamlined and direct than cone (or alpine, for that matter). Configuration is done either through the sidecar program “sup-config” (that speaks in a cowboy voice) or by direct-editing brief text files. And as you can see above, the results are practically oversimplified.

I plan to investigate sup more, and see if it will dethrone alpine at present. I like alpine and I am happy to have it around, but configuration is a huge complex chore, and even after roughly a year of use I still have points about it that I don’t like. I find it useful but something more concise might be better for a day-to-day email checker, which is all I really need.

Moving forward, here is canto, newsbeuter and nrss, alongside snownews, which I’ve mentioned before.

 

 

(Now before you get started telling me how canto supercedes nrss, I just want to point out that both are available in Debian, they behave a little differently and perhaps most importantly, nrss runs a bit faster for me at 120Mhz. It might be because canto is written in Python, and python is slower at that clock speed. I can tell you that ruby-based applications are particularly sluggish down here with the Pentiums, and it wouldn’t surprise me if language were the reason I see a difference between canto and nrss.)

I won’t claim a preference for any one of these, since they all seem to have similar styles and do much the same thing. canto probably arranges things in the most boxy style, with each feed in its own bracket. nrss is similar in its presentation, with keypresses for floating previews and jumping to a browser. Learn one and you’ve learned the other.

I used snownews for a while, just to see if I could get used to reading feeds, but it didn’t catch. snownews is akin to newsbeuter, with a file/folder approach that looks more like an e-mail reader. Nothing here is particularly different from raggle though either, which means it too could be an option. If feed reading is your thing and you want to dedicate one particular application to that, try one of these and see if it fits.

For a strict news reader, I can only suggest slrn.

I am in completely uncharted territory with news readers; I have no idea what or why or where the attraction lies, but if you can advise, I am an apt pupil. I managed to get this going and connected to gmane, but beyond that I don’t see anything that looks like “news,” so to speak. But like I said, I have no experience with these things, so I don’t know that to look for either.

Before this is done, here are two quick tools that you might find useful to read feeds, even though neither one is a full-blown “application” like the ones above. Here’s rsstail and rawdog.

 

“Oh boy,” you say. “One that spits titles into the terminal, and one that spews out HTML code. Yawn.” Yes, that’s right on both counts. rsstail basically trims a feed to specific components, and sends the output along elsewhere. And rawdog sends the results of its efforts into an HTML file, which is rather boring too.

But imagine where you can go from there: Rather than devote time to learning a whole new application for reading news, you send one instruction to cron to execute rawdog every hour (or maybe less), then bookmark the local output page in your browser of choice. Better yet, tinker with the settings and tailor the output to match your personal preferences for display.

And all you conky weenies still stuck to X in spite of my warnings to the contrary, you should fall out of your chair to realize there’s a command-line tool that takes up all of 32Kb in source code, that will inject the new entries from a feed into standard output. Good grief, the potential there is worth far more than 32Kb, and you get it for free.

I kid. Like everything in life, these things are only as valuable as the time and effort you invest in learning them. Maybe you’ll like them, maybe you won’t. If you do and want to brag about it, feel free; if you have others you think worth mentioning, I am always interested.

Quick and dirty: mplayer config file

I exchanged e-mails a day ago with someone setting up mplayer to run in much the same way as what you see in my screenshots. The config file I use for mplayer was helpful to them, and so I’ll post it here in case it is helpful to someone else.

really-quiet="1"
vo="fbdev"
vf="scale=400:-3"
framedrop="1"

It’s short and not terrifically illuminating, but

• the really-quiet option trims away any output to the console (with only one or two minor omissions);
• vo declares the video output mode as the framebuffer device;
• the vf option scales the output to fit half of my 800×600 screen and whatever ratio is determined by the file;
• and setting framedrop to 1 sometimes smooths out skipping if the codec is too weighty, or the transfer rates are slow (I usually keep video files on an external drive, and watch them across USB1.1).

mplayer has about a zillion options, but these are useful at around 550Mhz, and will handle most common output formats without overburdening the machine. I regularly used divx with mp3 playback when I encoded some DVDs, and the ogg sets work fine too. I have borrowed some movies from friends that had mkv or m4a (I think it was m4a … ) encoding, and they were sketchy at times. I mention that in case you have a 300Mhz machine somewhere, and you are wondering how much muscle it will take to watch your Spongebob Squarepants collection. …

vlc, ncurses and the framebuffer … ?

I have been using mplayer for years, and I find it handles most everything I require. However, I was enamored by vlc‘s ncurses interface a month ago, when I discovered it.

I’d love to use the same thing for video or audio playback at the framebuffer level, and I have seen pages elsewhere on the Internet that suggest it is possible. The problem is really, that my attempts to build vlc with no requirements outside of ncurses and framebuffer output (kind of like I did for mplayer) … well, they’re tedious.

I tried twice already to wade through the configuration options in a vanilla vlc tarball, but there are quite a few, and I am in very unfamiliar territory. The few I tried crashed for missing dependencies, and add the fact that I am doing all this at 550Mhz, and maybe you can see why this is a bit slow.

I have put this on my to-do list for when I find a faster, more powerful machine, but it might be a ways into the future. If you have any suggestions or if you know the proper flags to use when building vlc, please feel free to coach me. It would be greatly appreciated.

P.S.: I’ve seen the AUR package for vlc-nogui, which I used as a starting point. But I would prefer not depend on a lot of those things — like hal or sdl-image — if I can avoid them.

Four more for the console

I picked out four unrelated applications this time, more on the basis of their display than a central function. The reason for that is the one I’ve given a few times in the past: Applications that are a step above a single command can serve as replacements for GUI programs, and with much lighter requirements.

The first is abook, which is fun if only for following what looks like a tabbed index card shape.

I would guess that the real reason we have GUIs at all is to remind us of how an application corresponds to a real-world equivalent. That’s where the idea of the “desktop” came from really, from the idea of a desk littered with files and folders and tasks. abook does the same thing for an address book, recalling those small black books arranged by letter with a little pencil in the spine. Jot down a name and a number, and then wonder for the rest of your days who that was and why you wrote their name down.

Add a name, an address and e-mail or two, phone number etc. The nice advantage of abook over the little paper version is that it organizes and keeps things neat for you. My little paper address books were always quite scratchy.

abook is intended to work alongside mutt, although it certainly doesn’t have to. I don’t have mutt installed and alpine has its own address book functions for e-mail, so unfortunately abook probably won’t stay on my machine for long. On the other hand it is a nifty console application with a clean arrangement and easy interface. Couple this with something like wyrd and your entire office is manageable at the cost of something like 300Kb in disk space.

For a system monitor, here’s atop.

If it looks like top to you, it does to me too. Noninvasive, straightforward and packed with information. Doesn’t exactly scale itself to the space its given, but that’s not a requirement. On the positive side, it’s far from heavyweight and needs almost nothing to run (what you see there is over ssh between a Celeron and a Pentium, and there’s no drag whatsoever). On the negative side … well, it’s not htop. And we all know how popular htop is.

Here’s another console-driven file manager — clex.

Everybody has a particular file manager that they love, whether it’s Nautilus, PCManFM, Midnight Commander or what have you. clex is unorthodox in its arrangement, but perhaps the proper perspective is to look at this as a kind of enhancement to the shell.

clex has hotkeys for the standard ideas — moving files, copying things and so forth — but also for some unusual things, like user and groups information, or a shell command line. Some of these things are available in other managers, but some are unique (for what I’ve seen) to clex.

Many of us console weenies are bred into the two-pane arrangement and so in that case it might be difficult to get past clex’s list format. But this is one of those programs though that becomes more useful the more you use it … and if that sounds odd, just trust me.

Last, here’s ncdu.

This one I find myself coming back to quite frequently. I must agree that the standard disk usage command for Linux is a bother. If all I want to know is the amount of space a folder is taking up on the drive, I have a long and arduous string of flags to tack on to du before I can get the information I want.

ncdu, on the other hand, spins up fast, sorts everything in a jiffy and has enough small frills to make it absolutely indisposable. It doesn’t do much beyond show the size of a directory, but it will track down space hogs faster than they can reproduce, it will remind you of junk you meant to delete weeks ago, and best of all it has an easy-to-manage interface that almost makes it fun. This is another one I recommend as a program that does one thing, does it well and does it with flair.

As always, if you have suggestions or know of similar applications, I’d be happy to hear about them. (And yes, vifm is on my list. )

Lightning strikes twice

Some of my posts have gotten rather wordy lately, which I dislike so I’ll keep this one brief. Yesterday I went back to the same secondhand shop where I bought the 560e, and bought two things blindly that turned out to be winners. I know it’s bad form, since not everything is perfectly Linux-friendly, but I’ve been having good luck lately, and the trend continued.

The first was a memory chip found at the bottom of a bin of desktop parts. It has no more markings than “Nr64-16M,” but looked like the right size and dimension for PC66. It turned out to be a 16Mb chip that fits the 560e perfectly, although I really don’t have any more information than that. I should probably run a memory test on it, but thus far it seems to be working. With a total of 32Mb in that machine now, I can start using Debian (or Ubuntu) on it, and not have to worry about ducking the memory requirement.

The other find was a Buffalo LPC3-TX PCMCIA network card, which I intended as a replacement for the sketchy Corega FEther II PCC-TXD card I have been using off and on for two years. I picked it only because the box had no labeling on it newer than “Windows 2000,” and I figured that was a good stab at a 16-bit network card. (No CardBus support in my Pentiums.)

Debian says both cards are axnet-cs compatible, and even more surprising, they both lose network connections when traffic spikes. What I took for a hardware problem with the Corega card shows up in the Buffalo card too, which means the issue lies elsewhere. In any case, I dug the old one out of the trash and its boxing out of my paper recycling, and put it back in the closet.

Aside from that I spent a little time scoping out the used laptops, and have my eye on both an R60e and an X60, with neither machine costing more than US$600. I’m leaning towards Thinkpads these days, and those seemed like the most likely candidates.

See? Nice and short.

Rounding out a terminal-based Debian system

So long as I’m harping on desktops for Pentium-era machines running Debian, I might as well give a run-down on what I personally would (and sometimes do) use. Provided you’re not going to dedicate the machine to a singular task and imprison it in the closet, this might actually make a machine usable for you, all the way down to around 100Mhz.

Which release you use is up to you, since it doesn’t really affect anything except the version of the application … or whether an application is available at all. In that sense, I make no endorsement except perhaps to say that working out of testing is not all it’s cracked up to be. Yes, it’s as close to a rolling-release Debian as you’ll get, but the things I use still seem a step behind Arch or for that matter Crux. The same ground rule applies as ever: If you want stable reliable software you follow Debian’s style, and if you want something cutting edge you move out into the wilderness. Don’t be shy. Jump in with both feet.

First on the list and probably the most important, is to pick out a console font that makes your eye happy and uses screen space efficiently. Provided you have the framebuffer working on your computer (and if Debian can handle the framebuffer on this ancient, eccentric machine, it can probably handle yours too), I recommend something like the Terminus font. It’s strictly a matter of preference though.

After that, I would recommend screen, except that the Debian version does two things I find less-than-enjoyable. For one, it includes a single-character-width bar between vertical panels, which eats screen space and serves no purpose. Second, it always redistributes the screen space evenly, which I don’t want. I want to be able to adjust individual frames to suit the application I’m running.

For those reasons I recommend rebuilding screen from scratch and patching it manually. The directions here are aimed at Ubuntu but will work with Debian too; there may be minor differences in packaging versions but it worked fine for me and compiled in a reasonable amount of time at 120Mhz.

On top of that, and this might sound somewhat unusual, but I recommend installing dvtm as well. Why? Isn’t that hypocritical since you just knocked Debian’s screen for including a vertical divider? Maybe yes, but I say that mostly because screen and dvtm complement each other quite nicely. I would like to be able to group frames in screen and pop them in and out, but that’s not really possible. At the same time, once something is running in a dvtm window, it’s a bit awkward to shuffle around.

By combining them both, you can do things like paste htop and iftop in a pair of horizontally arranged windows in dvtm in one screen frame, label them “monitors” and bounce in and out any time you need a system or network profile. Purists will say that screen and dvtm are two sides of the same coin, but using them both in conjunction gives you a different and innovative way of managing parts of your workload.

It might be best to tackle the biggest issue up front: So long as you have a working framebuffer you have the ability to use links2 as a browser, and get a satisfactory graphical experience from an otherwise console-based experience.

Test runs at 120Mhz suggest this is a clean and brisk way to browse without overburdening the machine to a point of unusability. Firefox with Flash it is not, but if you are an unbeliever and demand a graphical browser on a Pentium Pro, this will satisfy. Furthermore, adding fbi to your system brings along fbgs, which allows you to display images and pdf files, respectively. For the reverse, try fbgrab and share your desktops with the world.

Before this turns into a list of random framebuffer-based applications, I’ll stop and say that my own personal preference is for the terminal-based applications listed here, supplemented with a few from here. Not everything listed is included in the Debian repos, but what isn’t there is usually small enough to compile at a low clock speed without waiting a week.

The converse of that is true though too — there are quite a few applications in the repos that I don’t even consider for my day to day patterns of use. Look into fbset for unusual terminal dimensions or rotated displays, jfbterm or fbiterm for an international terminal emulator, or some others.

I have a feeling my Debian adventure is drawing to a close, but I have no doubts I’ll be putting it back on this machine. I have a few more stops before that though.

A Windows XP-ish Debian at 120Mhz

The novelty in this is not in the desktop arrangement; I’ve been slowly tweaking and adjusting this setup for the better part of a year. In fact the fun part of this is that I’ve never been able to arrange it on this machine, even though I wanted to for quite a while.

One of my earliest coups with the late 100Mhz Pentium laptop, the close relative to this one, was a stripped-down Crux-driven IceWM desktop. But even at that early date, I could tell that a machine with only 16Mb was suffering with graphical interfaces — low memory meant constant thrashing at the swap space, and on a machine this slow, the delays were magnified exponentially.

Over time I pruned down toolkits and visual frills until the most usable and expedient X-driven desktop was running Xorg 7.3, Musca and an array of terminal-based programs. And it complemented the same array of programs I use daily on my other systems.

So really, this is not an improvement, just an experiment. I won’t be trading in the framebuffer-plus-screen setup I normally run for something that looks like the Windows XP Classic theme. On the other hand, it’s interesting to look at.

I’m still pleased with Debian for managing to keep things light, and at the same time streamlining most of the setup and tweaking required with building your own system. X, on the whole, is a bloated twisted train wreck of an application suite, and one I heartily recommend you drop like a bad habit. But until something better comes along, Debian can set it up quickly and efficiently.

It’s not all happy puppies and sunshine though. For almost half a decade now I’ve been flummoxed by the need (in both Debian and its offspring, to include Ubuntu) to bring in dozens of drivers for hardware that I don’t even own. I have software and packages on this Pentium now that represent the majority of PC technology for at least the past 14 years, if not longer. Why? I don’t know. I suppose it’s better to be safe than sorry.

Pointing the finger at X again, I know very well that it’s possible to run the C&T graphics card at a whopping 800x600x16, but Xorg 7.4 and xserver-xorg 1.7.4+/- can’t seem to handle it. I’ve even crammed a custom-edited xorg.conf file into its jaws, and got a bizarre, psychedelic rendition of what you see above. I would’ve needed leftover 3D glasses from Avatar to use it comfortably. Trust me — the 60s were not so great that I want them on my desktop.

So I drop back and punt (I think that’s the expression) and what you see is 640x480x24. Once I do that it’s where I’m trapped until I reboot though; it’s the same age-old issue I have with going back to the terminal after starting X in Ubuntu … and yes, I know how to fix that.

And I know I am fighting against the tide here, but adding hal-dbus-et-al to the requirements for X still simply annoys me. A year and a half ago you could get the same things done as now, just with less micromanaging and fewer daemons running interference. I still don’t consider that an improvement, and probably never will.

No, X doesn’t liberate a 120Mhz machine, since I still rely mostly on terminal applications. I have Xfe running in that picture, as well as a few other simple GTK2-driven applications in place (other toolsets don’t favor the XP look ), but honestly to get anything done, I rely on rxvt-unicode. (I only wish Musca was in the Debian repos. )

Redraws and shifting things are just too slow at 640x480x24 and I don’t remember 800x600x16 being much better with any graphical toolkit. Windows skip when I move them. The pointer flickers, and there’s a delay between clicking the mouse and the action on the screen. Startup is sluggish, and while it’s better than it was with 16Mb, it’s still irritating enough to warrant throwing the entire business overboard.

Which will be my next step, as soon as I get done typing this. Adding memory was liberating for this machine in the sense that it opened the choice of distros quite a bit. But after that, there’s not much it can do to make a graphical desktop more useful. I stand by my original suggestion: If you’re running a machine this old and want to use it practically, jettison post-7.3 Xorg, or stick with the framebuffer. It’s the only sane solution.