I have made a mistake

I take it all back. I apologize. I have been wrong for years now, and I have to admit it: You need a new computer. You need a faster laptop, a bigger LCD and a smaller netbook. You need a new computer for you, one apiece for your family members, and another for your home network. Get an iPad for your iDog, an iPhone for your iInfant, and get two or three wireless routers to manage it all, so you’re never out of reach.

There’s no shame in it any longer. I won’t harass you about the environment or materialism or social manipulation any more, I promise. I will not use the words “fanboy,” “brand imprinting” or “maximalism” again, unless it’s in a context outside consumer electronics.

You should think of a computer as a biennial — or even better, biannual expense, much like winter clothes or charcoal for the barbecue. Pick any regularly observed holiday in your country of residence, mark out an even six months on either end, and call that New Computer Day. You can build up the excitement by festooning your abode with any number of calendars or decorations — just like before Christmas or Easter or Mother’s Day. Or maybe even better, you should use another new computer to count down the hours until the next one arrives.

Computers are disposable, like diapers and tissues, and should be thrown out at the end of a good run of six or eight months. The hardware decays, gets slower, grows unstable and unreliable. And everyone knows the software is designed to last for only one or two startups. Sort of like running shoes or brake pads or light bulbs: After some use, you’re safer and smarter to go buy new ones.

And of course, I apologize again for misleading you all these years with suggestions that out-of-date systems are viable alternatives. That’s obviously just not true, and I committed a grave error in saying that. Get out there now, pick out a brand-new machine, and plunk down the US$2000 or so it costs to bring it home. That’s less than US$200 a month really, and I know people who spend more than that on baseball tickets or gasoline or dairy products.

What you do with the old one is not really important any more. But as I mentioned, computers are ephemeral and disposable, so probably the best idea is just to toss it out.

I patiently await the fruits of your ignorance.

Three plus one: disk usage meters

I keep ncdu installed as a matter of course. It’s one of those tools that I wish I could use more often, because what it does is very cool and very useful … just not very frequently.

I suppose disk usage meters in general suffer the same weak point — aside from perhaps a once-a-month file weeding, I don’t need them very often. The idea of a disk usage meter isn’t innovative either, seeing as you get du as a free gift in most distros. But what du lacks in presentation, others make up in style. ncdu was one example, and here’s another: gt5.

Depending on your personal preferences, you might like how gt5 tackles the issue — pushing its results into a text browser. After arranging directories by size, it creates an HTML file with internal links to pages that show directory size. You saw this this in the screenshot if you noticed that the page shown by elinks is a local address, and that the paging indicator runs up to 185. Go ahead, click again.

In that way, you could take what gt5 outputs, and rearrange it for use in other ways. Open the same page in Firefox, and you get a similar result: a black page with color-coded links, file and directory sizes, and so forth. So gt5 creates something flexible and usable, beyond just showing you where the chunky files are.

(I should also mention that gt5 by default screens out some of the smallest files, which is why the directory arrangement in gt5 looks a little different from others.)

For a strictly tree-style view, tdu might be interesting to you.

Available from the same site as vtclock, tdu works in tandem with the aforementioned du command to build the tree you see there. You’ll need to pipe du through tdu, in order to get results: du /home/kmandla | tdu for starters.

tdu has a decent man page and a pair of help pages while it’s running too, so getting it to behave how you want shouldn’t take too long. For dependencies it needs almost nothing short of ncurses, and the results are more visual than the other two. Rather than just directory-by-directory lists of sizes and files, you move through the tree via keyboard, opening and closing the tree structure in much the same way as many other file access utilities.

If that appeals to you, you can probably better tune du and tdu to work together and get the results you prefer. Personally I find du‘s default file size value to be completely unhelpful, so the -h flag might be the first place to start.

I don’t usually mention graphical tools any more, but it seems worthwhile to point out this one: fsv.

 

fsv is a little dated, what with the GTK1.2 interface and the rather old-school button images. In that sense, it won’t be as taxing on your hardware, even if it will require a little muscle to run. …

A little, in the sense that the 3D animation effects will ask more of your video card than any of the previous three. Clicking a directory shows a zooming effect, and expanding it via the right-click menu causes folders and files to stretch up like towers. Moving between directories on the left makes the view slide gracefully to its new point, a la Hollywood blockbuster special effects … sort of.

But after that, and aside from looking over the directories and files in your tree, fsv doesn’t do much. It has some basic file management abilities, but otherwise it’s nothing terrifically functional (I hate to use the word “gimmick” here, because it has some negative connotations. But really …).

So perhaps a talented coder will pick up fsv and give it a proper makeover (Edit: There is an fsv2, by the way), and add some fun(ction) to it. It seems like the basis for an interesting tool, but as it stands it’s just backdated and a bit thin. I suppose it would be useful in some sort of big-budget animatronic dinosaur movie though, if the production team decides not to pay for a Windows-based prop in their film. …

P.S.: Images courtesy of Musca and Arch Linux.

cdm: Manage desktops from the console

The bulk of my systems are console-driven, and on the one that does run a graphical environment, I don’t use a display or desktop manager or login manager. There are some very good ones out there — SLiM is something I’m familiar with, as a result of working with some ultralight distros, and Qingy is another one with a long-ish history.

But mostly the need just isn’t there. I send the boot process straight through to the desktop via /etc/inittab, and beyond that, there’s no reason for me to use a display manager.

Now if I was to use one, this is what I would install:

That’s the Console Display Manager, or CDM. It was announced in an Arch Forums thread started a couple of years ago, and began as a bash-only text-based login manager to take over the jobs of GDM, KDM, xdm, etc. As I have it installed, it still requires you to login at the prompt, but bounces you first into a menu like the one you see above, and let’s you pick your destination from there.

Configuration is in /etc/cdmrc and is very well described, so you shouldn’t run into too many problems setting it up. It’s tuned for Arch Linux of course, with a PKGBUILD in AUR, but it should be fairly easy to export to other distros — especially since it comes with practically no dependencies.

One thing I would like to try, but I haven’t yet, is to cue CDM to different shells instead of desktops. It seems like it should be possible to trigger zsh or dash or what have you, in the same manner as the X environment. Again, I haven’t actually done that, but it might be a bonus for people like me, who don’t really want X in the first place.

vtclock: One more console clock can’t hurt

Just a short note today, about another possible clock and/or screensaver for your terminal-only system. This is vtclock, running in screen-vs.

The home page insists the only thing needed to make this work is ncurses, and so I am fairly confident that it will build on your system. The source code dates back to 2005 and might show a warning or two when you compile it, but I had no difficulties on my Pentium. Expect it to finish in under a minute, no matter what you run.

This one doesn’t scale itself to a window size, like clockywock, and doesn’t occupy a small enough space to be “portable,” like tty-clock, and doesn’t seem to do color like binclock … but it’s very visible and has four different “fonts” outside from the one you see there. (Commodore junkie alert: No. 4 appears to be very close to the old C64 font pattern. … )

The real nifty tricks are the -p and -f flags, which allow you to add arbitrary text, either from a file or a command, to the display a line at a time. So you can tack on something like date, as you see in the photo, or even something else like a wifi status or the tail of dmesg. It’s very convenient.

But that’s all there is to say about it really — it’s simple and clean and does what it says. Add it to your array of screensaver gizmos in this fashion, and bask in the phosphorescent glow. …

A short interlude for blasphemy

This might hurt you to hear it, so if you have a weak constitution, you might want to look away: I installed Windows 2000 on the Sharp Mebius and I am happy to say, performance was pretty crappy.

Let me repeat that, in case you think it’s a mistake: I put Windows 2000 on a 150Mhz Pentium with 32Mb of memory, and it ran like a dog. And I was glad to see that.

No doubt you think that’s some sort of twisted Microsoft-hate thing, but really it’s not. I don’t normally laugh at unfortunate situations, and poor computer performance — aside from BSODs in airport lounges, or something like that — aren’t particularly humorous. No more than putting the wrong fuel in your car.

Let me give you a little hint: Counter to popular opinion, I don’t hate Windows. I just prefer not to use it. In fact, I’d even go so far as to say that some versions were actually passable. There’s nothing out there now that I would ever consider paying money for, but 10 years ago, I was quite happy with Windows 2000.

In fact, that’s probably the last version of Windows I hold any endearment to. It might just be the way things were in the world a decade ago, and it might be some sort of rose-colored-glasses effect. Regardless, I hold no animosity — but no love either — for any particular Redmond product. Except that Win2K happened to work quite well for me.

At the same time I’m well aware that most of the machines I work with have a strong attachment to turn-of-the-century technology. I expect them to perform at certain levels because they date back to that era. So no, I don’t expect to run Compiz on a Pentium, even if I do make that joke at times.

But a lot of what I anticipate, in terms of performance from Linux, et al., is tied to what those machines can do, given the software and hardware of that era. If I get crappy performance from a GTK desktop running kernel 2.6.34, I expect crappy performance from a modern version of a proprietary OS on that same machine. By the same token, I expect to see decent performance from an operating system that is a contemporary of that hardware.

Does that even make sense?

Anyway, for a year or two now I have had a sneaking suspicion that my efforts to minimize bloat and keep obsolete machines afloat was running aground, mostly because the graphical systems I was building on very, very slow machines were so sluggish as to be unusable. Now and again I was reassured that it could be done on even the slowest of hardware, but as a generalization, it was never very satisfying.

So when a friend lent me a Windows 2000 CD (which barely booted, it was so old and scratched up), I wasn’t sure I wanted to see the results. In my mind, I was going to be disappointed by the speed and quickness of an operating system that was more or less appropriate to the machine.

But I was pleased to be disappointed. Windows 2000 took two or three minutes to reach a usable desktop (like some Linux systems I have built), cached endlessly (like some Linux systems I have built), and failed to identify a lot of the hardware in the machine — most notably, the network card. It was slow to start programs, useless on the Internet (with IE or Firefox), and grumbled a lot when I wanted to set up the unconfigured parts of the machine. And I was happy at that.

There were some good sides to the encounter though, such as …

That would be the shareware version of Diablo, a game that predates even the computer it’s running on. After I finally got everything set up, I racked my brains trying to remember freeware or demo versions of games and applications I used 14 years ago, and see if they were still downloadable.

Most of them were — things like SimCity 2000, the demo version of Microsoft’s Age of Empires, Descent 2, the Quake demo or even Duke Nukem 3D. And some of them I was half horrified, and half shocked to remember the system requirements. AoE, just for an example, will supposedly run on a 90Mhz Pentium with only 16Mb of memory in it. And miracle of miracles, the original Descent demo needs only 4Mb and DOS 3.1 to work! Has it been that long?

Windows 2000 barged through most of them without an issue, and the bulk of them performed rather admirably, given their age. I am ashamed to admit it, but I think I actually played out an entire scenario of AoE, before succumbing to nostalgia.

In any case, Windows 2000 was in both ways a disappointment and a surprise on that machine. I was startled and then pleased that it performed and set up so poorly, but at the same time I was pleased that it reintroduced me to some of those games. I know I mentioned it myself a long time ago — that there’s no shame in using an old computer to run old games — but perhaps I should occasionally take my own advice.

More distros at 150Mhz, both good and bad

Arch Linux isn’t the only thing I have installed or used on the Mebius, since I brought it home a week ago. I did a few trial runs with other distros and OSes, although not all of them were as successful as archlinux-i586.

• Debian, oddly enough, mentioned memory errors after a network installation, and refused to boot. Unfortunately I didn’t write down the exact error message, so I don’t recall exactly what the problem was. I plan on trying this again sometime in the near future, mostly because Debian is one of the best start-from-scratch, intermediate level distros out there, and it runs on old, old machines like this.
• Damn Small Linux in its last incarnation — 4.4.10 — worked perfectly, finding all the components and even getting online with help from the network configuration interface. I know it is long, long out of date, but it’s hard to argue with a complete, full color, native resolution desktop on the first try, on a machine that old. It’s still worth keeping around.
• I thought Tiny Core Linux would also hit a home run, but oddly I was left at a command prompt and didn’t get much farther than there. I blame the graphics card for that, which might sound strange. But I know this Trident-based card is VESA 1.2 only, and it might be that Tiny Core is going straight to the framebuffer, which it can’t do. Ironic though that DSL works where its successor doesn’t.
• KolibriOS, for the same reasons, was less than successful. While it booted and behaved more or less as expected, the video card was too outdated to make full use of that OS. Boot times from the floppy were about what I expected though, so there wasn’t much more to see than what I have already seen in the past.
• Slitaz wouldn’t boot, but that’s my fault. I only have the full 3.0 version on disc, and what I probably needed was the loram revision. Even something as light and speedy as Slitaz needs a little space to get started.
• Crux i586 has been the strongest contender yet, and amazingly I managed to put together a kernel that booted on the first try. I still have some issues to iron out — such as forcing the correct resolution to the framebuffer, because the kernel always jams 640×480 into it, and I want 800×600 — and memorywise it tells me it hasn’t got enough to build anything (which is possible). Your puzzle for today though, is to figure out how I get Crux onto it in the first place, since 32Mb is definitely not enough to load up the Crux i586 boot disc.

I still want to try Puppy Linux, the correct version of Slitaz and a few other lightweight operating systems. As always, if you have suggestions, I would be happy to hear them. Next up is a small dose of heresy.

The myth of Arch Linux and the i586

Jared asked the right question yesterday, when I proclaimed I had Arch Linux running on a Pentium MMX machine. How does a distro cut to fit the i686 generation downscale to an i586? After all, the two architectures are different, and software compiled for the newer, as a general rule, can’t run on the older.

Well, never let anyone tell you that Arch Linux won’t run on an i586 machine. It’s not true. It’s not intended to run on an i586 machine, but that doesn’t mean it won’t. It just means it’s a bit more work.

Arch has always won points — and will always win points — for being easy to customize to the machine you use. That is why many people use it: You can achieve almost any result with Arch, and get there via the path of least resistance.

At the same time, Arch saves you an immense amount of time by allowing you to avoid building software from scratch. I will be the first person to acknowledge that yes, while I enjoy working with Crux, the wait for system updates is directly proportional to the age of the machine. And sometimes, it gets scary.

But there have been many attempts to share Arch’s ease of use with other, outside architectures, but sadly they always seem to sputter. There was the Lowarch project from a few years ago, which I still seed the torrent for. And about a year and a half ago I mentioned the archi586 repos, which you could use to hopscotch up to then-current.

Around the same time an archlinux-i586 effort popped up on Google Code … and seems to have slipped away as well. Most recently (perhaps) is the archlinux-i586.org site, but its repos are now offline too. (Although there are some updates at github, where the project seems to have been hosted.)

I don’t hold out any hope for a sudden upsurge in the demand for an i586 version of Arch Linux; I have seen enough of them come and go to know that they’re unlikely to take hold. On the other hand though, any one of those should at least get you started, and give you the chance to put a version of Arch into place and work your way up.

But what about updates? How do you move from, for example, the last available Arch Linux ISO tailored to an i586 machine to current?

Well, unfortunately, you’re probably going to have to get your hands dirty. The aforementioned ease of installation that comes with Arch on an i686 machine is sometimes, occasionally also available for i586s, but even without it, you can get the job done. If you compile by yourself.

Now I don’t like to build software on machines as old as this, and generally speaking if I have to make updates to it in Crux, I yank the drive and chroot via another computer. I can borrow the processor on this machine, for example, and update in a fraction of the time it would otherwise take.

Arch, on the other hand, has some nifty tools for building your own versions of software, and transporting them across international boundaries.

The most obvious, and among Arch’s Greatest Hits, is the abs tool, which will mirror the current Arch build scripts onto your local system. From there, almost anything is possible, so long as you’re willing to take the time to build things yourself.

Personally I suggest doing this on a faster machine, if you have one you can spare. Sync with the abs tree, then rsync that into your home directory, in something like /home/kmandla/i586/abs. From there you’ll need to make a custom makepkg.conf and abs.conf file; I suggest

cp /etc/makepkg.conf ~/.makepkg.conf
cp /etc/abs.conf ~/.abs.conf

Edit one or both of those to match your architecture (here’s the Gentoo wiki page on safe CFLAGS, which you’ll want to check), and from there you can build packages as a non-root user, for an architecture other than the host.

If you like, you can tell makepkg and makeworld to dump the results into a destination folder (i586/pkg in my case), and then build a portable repo to move between machines. Once all your packages are in place, use the repo-add command to create a database file for all those packages. And you can shuttle that entire business between machines to install. Of course, you’ll need to tell your target machine where to find the database file; try adding a file:///-style entry to /etc/pacman.conf, or inside /etc/pacman.d/.

There are much better instructions on the Arch wiki pages for Installing to i586 and Custom Repos. In most cases, the flags and configurations listed there worked perfectly for me.

I can offer a few tips though: For one thing, if you build a custom repository for updates, make sure the name of the database you create matches the name of the database the original packages came from. For example, if you’re building an updated version of udev (just as an example), make sure you put it in a repository called “core,” because it was installed from the category “core.” If you don’t then your system won’t update properly, and you’ll have to upgrade packages one-by-one.

Additionally you have logs about package build results, but for my case, the log was filled with “failed” builds (which were actually fine). The only way I could see if there was a truly failed package was to compare the build log with the contents of my pkg folder; if a package was missing, it didn’t get built.

The only things that have failed spectacularly with this heart-transplant system are the kernel structure. That makes sense though, since you should probably build and package a kernel in another fashion, rather than by trying to rebuild the stock PKGBUILD with just a different architecture.

Oh, and makeworld for the core repository only on this machine took over 400 minutes to complete. So be aware.

I should finish by saying that I didn’t bother installing X or anything even remotely graphical on the Mebius, mostly because I have no interest in laboring a machine of that era with a graphical desktop. Or do I … ?

P.S.: Sorry this post was so long. And whether or not the same stunt is possible with Ubuntu after Meerkat remains to be seen. But probably not by me. The idea is so unattractive as to be laughable.

Arch Linux on a 150Mhz Pentium MMX

I have about three posts stacked up in a line, waiting for one in particular that needs published, and so here it is: I found another Pentium machine, and I have a feeling this one is a real keeper.

This is a Sharp Mebius MN-340-001, which the Sharp pages (still!) suggest dates back to February 1998.

For a Pentium MMX machine, this is rather satisfying all-around. CPU is clocked at 150Mhz, standard memory at 32Mb EDO and an 800×600 LCD. Floppy drive right up front, touchpad for those who cannot bear to abandon the mouse, and even a CDROM this time — which is a huge blessing after working with this machine for so long.

Even better, this actually has a single USB1.1 port at the back, and to be honest, that was the reason I snapped it up at the recycling shop.

But best of all — and this might be hard to believe — the battery holds a charge for almost two hours. I know what you’re thinking, because I was thinking the same things after I brought it home. But honest-to-goodness, I can charge the battery in about an hour, and it will discharge completely after about two hours disconnected. It’s mind-boggling.

I was a little worried because the video card is Trident-based, and machines from that generation with Trident hardware have given me difficulty in the past. Fortunately though, this one seems to be strong enough (2Mb VRAM … wow!) to handle the standard Linux tridentfb module without an issue.

The geek rundown is as follows:

• Pentium MMX processor clocked at 153.4Mhz, according to /proc/cpuinfo. It also says CPU family 5, model 4, stepping 3.
• Intel 430TX chipset. Kernel 2.6.34 uses the piix and ata_piix modules, if I remember right.
• 32Mb PC66. 32Mb is more than enough for my day-to-day use, and unless I want to run a live CD or something from memory, I can’t think of any situation that requires more than that. I have a spare 64Mb stick of PC100, but while the slot matched, it was to tall for the bay.
• 2Gb Hitachi MK2104MA hard drive. Slow, small and noisy. Like all hard drives from that era. It whines to no end, thereby annoying me to no end.
• Trident 9660 video card, if lspci is to be believed.
• One USB1.1 port, rear. If it didn’t have this USB port, it would probably still be sitting on a shelf in the recycling shop. I know I can be finicky when it comes to computers, but anything in the Pentium generation that has a USB port on it is suddenly a must-have for me.
• Matsushita UJDA110 20X CDROM. Oh good grief, I forgot how slow 20X was. But it’s a working, error-free CD drive, which is a thousand times better than no CD drive at all. The BIOS allows it to boot from CD too, even if booting from USB is a no-no. And this time, PLoP doesn’t seem to help.
• ESS ES1869 sound card, I think. I usually leave sound to last for configuring, and take my time with it. A looong time.
• PCMCIA CardBus support, in the way of an O2 Micro-based bridge. This is the first time I’ve worked with anything other than yenta or pd6729, and so I didn’t know a 2.6.34 kernel would require embedded support to get to the yenta-O2 option. Who would’ve thought a 12-year-old Pentium would require “embedded” software support. …

I think that’s about it. It has a few other amenities that would have made it a real Cadillac in its time, like a serial port and a floppy drive, and things like that still come in handy for people like me.

The chassis is in excellent shape and the screen is in good condition. It seems to have some speckling effects here and there when the screen colors are bright, but it’s certainly not in any way damaged or unreadable. And there’s one scuff on the lid at the top right, which I might be able to buff out.

But other than those minor points, I really, really like it. It has all the little finishing touches that I wish were on this machine, and it’s in excellent shape to boot. And that working battery is still just … unbelievable.

That’s all for now; I’ll have some more war stories over the next couple of days. I’ll leave you with one final kick though: The screenshots you see there are of Arch Linux.

hal’s day of reckoning

I have been waiting for this for about a year and half now, and today, finally, I get this on my Arch system.

Since around November 2008 I have had the singular displeasure of heaping blame upon hal whenever something went southward in a system I built. Forgetting to start it up has killed more installations and caused more filesystem errors than I can count. Just managing an international keyboard with hal was an exercise in relearning everything about X-and-company.

Not that there’s much to love in Xorg in the first place, but dealing with hal as an intermediary ranks near the bottom on my all-time least favorite things to do. Somewhere around “walking barefoot on broken glass” and “getting a root canal.”

I for one welcome our new udev overlords. I can’t be sure at this early date that things will be better than they were with hal, but I am reasonably confident that they won’t be worse.

P.S.: This Arch wiki page may be very important to you.

twin, vwm and my imagination

A lot of times I run across software that I want to like a lot, but somehow doesn’t seem to work quite right. It’s not because it’s somehow faulty or misdesigned, but because I happen to like the idea in principle: It strikes me that it ought to work as well as — if not better in — real life.

Both twin and vwm are like that. In my imagination, it should be a no-brainer to run a windows-esque terminal session, complete with floating frames that overlap and have primitive shading effects, to control it with your mouse and to watch as your geek friends all fall over in a dead faint from the exuded coolness.

And yet it never seems to pan out that way in reality. I’ve mentioned twin in the past, and it does an admirable job of pursuing that dream … and yet seems to be pushing toward splicing that goal with an X environment. Just as an example, if you run twin under X, you get graphical effects here and there, for scrollbars and buttons. Maybe a picture would be more helpful.

Of course running this in a terminal doesn’t give you those effects, so it’s strange that I should feel disappointed in them. It might be that I feel a little sadness in seeing something turn toward an X environment, when it seems so obviously perfect for a non-X one.

vwm, on the other hand, seems to be fighting me, and I seem to be losing. Short of this screen, there’s not much I can show you.

vwm needs a lot of unusual dependencies, and for that reason I haven’t bothered building it on my Crux systems. As you can see it looks a lot like twin, and similarly I would like very much for this to work as I imagine it. But vwm ignores almost everything I do to interact with it — most importantly, my ALT+tilde commands to start a new window, or my ALT+w keypresses — “manage windows” — which just trigger strange lockups.

Those things might be the fault of using a Japanese keyboard. The tilde is a language control function key, and the actual tilde is on the other side of the keyboard. It seems no matter how I press or combine things, whether at a tty screen or in an emulator, vwm is imperturbable. My keys are ignored.

Maybe I’m overreaching on this to blame it on a keyboard layout, but at the same time, I can’t find a .vwmrc or an analogue, there isn’t a man page in the Arch version and I can’t get any tips from vwm --help. I even went so far as to decompress the source code to see if I could feed it another key, a la dwm’s configuration method. I did find a VWM_HOTKEY_MENU variable inside vwm_hotkeys.h, but I don’t know how to correctly adjust that value with any measure of predictability.

In any case, that’s more time than I like to spend goofing with a program — adjusting the code to sidestep keyboard discrepancies. So I am left with a pretty green screenshot and a halfhearted thumbs-up, suggesting that maybe it will work for you, even if it didn’t for me.

But I could say that about anything really, and it rings rather hollow any time I do. As it stands, both of these programs seem to approach that image in my head that I mentioned earlier, but are either veering away or falling short. Maybe they’ll do a better job approaching the image you have.