Well, look what we have here. …

Onyros on the Ubuntu Forums gets a big gold smilie for pointing out a fantastic cache of extremely lightweight software, most of which is written in Python, if I am reading it right. That means just about anything with a working version of Python should be able to take advantage of them.

I have a rack of things that need to be done in the immediate future, but I’m looking forward to experimenting with weblink, Droopy and a couple of other things posted there. I have a feeling some of it might be great for cross-the-web transfers, or even just across-my-network transfers when other methods seem inappropriate.

In any case there’s enough stuff there to keep myself busy for at least a day, if not a whole weekend. If you find something fun and want to brag about it before I get the chance, please do.

Okay, Onyros, here it is:

Suddenly things make sense

I’ve been a bit flustered by my ancient laptop recently, mostly because an extra 32Mb stick of PC66 doesn’t seem to be recognized by the system — BIOS or otherwise. I tried inserting another chip — a little faster one — in the hopes of at least triggering an error, but nothing happened. And I see no BIOS options. And I see no dip switches. And that might mean things are now might be as good as they’ll get.

That would be sad, because there’s a lot of potential there, but without enough memory to scrape by, it’s difficult to do anything beyond the console. I still have the option of a larger, faster hard drive (which I intend to pursue), but unless there’s another memory brace buried somewhere in the guts of the machine, I think the easily accessible one is broke.

So I’m in a situation where graphical systems are laggy because there’s not much memory, and extra-laggy because the paging to the drive is so darned slow. Icons, menus and program selection can take 10 to 20 seconds at a time because of all the caching and refreshing that needs done. Little things like turning off antialiasing, and using only console applications lighten the load enough, but anything with menus or scrolling or whatnot takes forever to manage and use.

What I really need is to focus on console-based applications and ignore anything graphical, find a window manager that doesn’t drag at 100Mhz, that can duck in under the wire at 16Mb and still look good without requiring glossy titlebars and stuff like that.

If only there was something like that. If only there was … if only … if only. …

And suddenly everything makes sense. A long time ago I spun past awesome, trying to figure out what the appeal was. Now I know. Yes, this is still a graphical system, so it’s not any faster than, say, Openbox in starting up. It still causes some rather hefty disk-thrashing on general use, and yes, it’s about as heavy as IceWM, if htop is to be believed.

But this is ultra-cool. This is a 100Mhz machine with a sweet desktop presence, system monitors, chat windows, you name it, everything running from the keyboard (which is a good thing, because moving the mouse can trigger more disk access … I have no idea why) and nothing graphical to slow it down.

Technically that’s the old version of awesome — 2.3.4 or something, out of the Crux 2.4 repos. Xorg 7.4, the updated version or the version that comes with Crux 2.5, won’t work on this machine because it fails to recognize the video card. And building the newest version from a 2.5 port is a bit time-consuming, when I could just be using the machine.

So far I’ve put Openbox on this, as well as full and light versions of IceWM, and if you want to count the original system, Windows 95. But this is by far the coolest, geekiest, technophiliac-est way to go, for a machine of this caliber.

P.S.: Thanks to urukrama for keeping my 100Mhz experiment from looking like the bottom of a birdcage.

Build up, don’t tear down

I found a nifty link to some more speedup tips for Arch. In fact, there’s a whole thread here that talks about ways to make Arch boot in a half or a third of the time it takes normally. If you use Arch and you’re not one of those people who runs a machine 24-7, you might find them interesting.

My own speedup tips for Arch are scattered around this blog, with most of them under the Howtos page, but all of them a couple of years old already. I still use Arch, but I don’t bother tweaking it for speed any more. My philosophy toward it has changed a bit.

I left Arch for Crux when I realized I was falling into the same habit I had begun a year before, when I started carving down Ubuntu in hopes of speeding it up. The problem is that both times, my perspective was a little off-kilter.

For my own part, building a system up from scratch is always faster than tearing out parts of another one. I don’t think I’m stepping too far out on the limb when I say that; it’s common knowledge that a Linux system crafted from the ground-up is going to outperform anything that was torn down.

It’s true for Ubuntu — a command-line system with desired packages added on top is going to run faster, probably, than one that was cut down from the complete version. The same thing is true for Arch: When I started recompiling entire systems with different CFLAGS, or building custom kernels, or carving out the default init scripts, I realized that it was time to look for a different brand.

Making Ubuntu into Arch isn’t any more promising, to me, than making Arch into Crux. The work you go through trimming away at Arch is sidestepped completely with Crux, and for some people that’s ideal. It’s true, it’s the difference between an intermediate distro and an advanced one, but if you’re doing all those things in Arch, then you’re ready.

If that sounds like you, I would recommend considering something that gives you more ground-level control, in such a way that you’re not taking extra time slimming things down when you could be building up from a pure core. And if performance is your goal, then the results will be very gratifying. After all, a 16-second boot in Arch is a grand thing on a dual core, but I get those numbers from a 550Mhz Celeron, just as a matter of course.

Think about it. If you want to ask questions, there are a few of us Crux experimenters floating around here, in addition to the standard Crux IRC and mailing lists. And what we don’t know we can research together. It’s part of the learning process.

The most annoying Firefox thing

If you can get this to work on your system, you’re a better person than I.

firefox -width 800 -height 600

I can’t remember the last time the command line height and width flags worked in Firefox. I don’t know why those flags are there, or if they’re broken, or if they’re deprecated, or if they’re a huge joke the Firefox brainiacs like to play on us normal people. Maybe I’m just using them wrong, or maybe it’s annoying regardless.

But I got tired of resizing the windows every time I moved a profile or changed a screen dimension. So I found two ways to convince Firefox that “me-Tarzan-you-Jane,” and start at the size I want.

The first is to manually edit the localstore.rdf file in your profile, and set the desired size. Of course, that file can be overwritten in the course of using Firefox, so unless you employ a script to open the browser and then restore your preferred sizes after Firefox closes, it might not work on a permanent basis.

Instead, what I’ve been doing is to change the prompt from Openbox or wbar to this:

firefox javascript:%20resizeTo\(800,600\)

Note the two backslashes in that line, to escape the parentheses. No matter what your last dimensions were, the screen should bounce back to 800×600. You could conceivably set your home page to that too, if you don’t mind opening Firefox to a blank page, or if you want a one-button size fixer.

Personally I prefer to keep that at the command line, because I can trigger different sizes depending on the situation. In any case, it always feels good to remind Firefox that I’m the boss, no matter how popular and big-headed it has become.

And like that …

Poof, it was gone. I moved too slowly on the Thinkpad at the recycling center yesterday, and when I visited again this morning, it had been sold. I had it in my head this morning that I’d stop in and check once more, give it a look over and then decide if it was a keeper. In the end, somebody decided for me, and in a way I’m glad.

It’s probably just as well. I need to sort out what I’m going to do with the machines I have, before I start taking on new ones. And I would do better to upgrade or improve the ones I have instead of bringing home more wounded soldiers.

So the lesson learned is, “Impulse buy.” Or maybe it’s, “Never pass on a Thinkpad.” On the other hand, the lesson learned could be, “It’s easier to let someone else buy it, than to rationalize the purchase of another computer.” Or, “You can never have too many Thinkpads.” It all depends on your perspective.

Unfortunately, my perspective is a little cluttered. You see, there are all these computers blocking it. …

Case in point: A Crux ports server at 100Mhz 16Mb

I have five machines all running Crux now, although that number is apt to fluctuate from time to time. With that many machines all updating their ports libraries directly from the Internet, it only makes sense to give that responsibility to one machine, and let the others refresh themselves from it.

And it only makes sense for that one machine to automatically refresh its own tree once a day, or perhaps even twice a day, and serve those ports to the remaining machines whenever they need it. The server doesn’t have to do any real compiling — in fact, it’s probably not going to do anything at all, just sit and wait for another machine to request fresh ports.

I think I may have found the best use yet for my ancient laptop.

The ironic part is, this is terribly simple to set up. crond can handle the important role — automatically refreshing the system ports — and NFS makes the actual serving of the ports no more difficult than mounting a directory and copying them across. An rsync command from the root account of the client, and it’s done. Lower bandwidth and no need to swamp the Crux servers with multiple machines updating individually.

The first step in setting it up is to build a kernel that can act as a server. NFS is activated under the File systems::Network file systems options in the 2.6.28 kernel, and there’s a separate option for the server and the client. I’ve activated both on my machine, but that’s also because I use the battered Thinkpad as a way of transferring files across machines, and I want to be able to mount that as a normal user, and read and write to it.

Once the kernel is built, you’ll need to set up the server and trigger it as a service. The best place I know for information on setting up an NFS server is the Arch wiki. After that, both portmap and nfs-utils need to be installed on the server. For export options, I used this:

/usr/ports/ 192.168.XX.1/24(ro,sync)

Since there’s no need for clients to write to the directory, I set mine to read-only. Other options, for example the ones on the Gentoo wiki, also seem superfluous, and so I don’t enable any of those either.

I’ve had trouble starting the server when I manually enable the network through /etc/rc.local, so I use the same commands in the /etc/rc.d/net service instead — everything from enabling the pcmcia socket with pcmcia-socket-startup and setting wireless options with iwconfig, to starting dhcpcd.

Now it’s time to set up crond. This is even easier, since there’s only one file to make, and one file to edit. Open up /etc/crontab and adjust it to your liking. Personally I just want the ports updated once a day — more than that seems overdone. Perhaps with another distro you might want fresher updates, but in my experience, once a day is more than enough for Crux. Here’s what I used to get updates at 7:30 a.m., local time.

30 07 * * * /usr/sbin/runjobs /etc/cron/daily

And in the /etc/cron/daily folder, make a file that says only this.

/usr/bin/ports -u

Don’t forget to make that file executable. I wondered for a long while why cron wasn’t doing anything, and then I remembered that.

After that, just make sure crond, net, portmap and nfsserver are all triggered in your /etc/rc.conf file, so the entire business is ready at boot.

For clients, I edited my /etc/fstab files to include this line.

192.168.XX.XX:/usr/ports /media/ports nfs noauto,nolock 0 0

I like to mount external files and drives to the /media folder, and symlink into the home directories to access them. The noauto flag doesn’t mount it at boot, and nolock helps avoid a weird two- to three-minute delay when I mount the network drives. Notice that I didn’t include the users flag, which would have allowed normal users to mount the server too. I see no point in that, since normal users can’t synchronize the ports tree anyway because they don’t have write permission to the local /usr/ports folder.

Once that’s in place, I switch to the superuser account, mount the network drive, and use this to sync the local tree against the server.

rsync -a --progress /media/ports /usr/ports

I can still update my ports tree manually, and I can still edit and maintain ports unique to each machine or keep source files on a local machine (such as the proprietary wireless firmware for my Intel PRO/Wireless 2200BG). There are no source packages on the server, no binaries, but the patches and extra files can remain there as well. Best of all, if I need to rebuild a machine, it’s easy to get a fresh tree without relying on access beyond my local network.

The erstwhile dealbreaker flaws this machine has — the noisy, small hard drive and the relatively nonexistent RAM — don’t really matter in this role. Since the ports tree is only refreshed once a day, and it’s first thing in the morning, it can do it’s job and be noisy for a little bit, then sit idle and quiet for 23 hours and 55 minutes. (To ease your environmental concerns, the wattage rating on the AC adapter is 60W, which in my mind ranks it about the same as the light bulb in my kitchen.)

And the final touch? Installing cmatrix so the machine has something fun to show, while it’s sitting, counting the seconds until the next ports update. Now tell me: Can you think of a better use for an extra 100Mhz laptop?

P.S.: I suppose you could do this for some other script-based distros, or perhaps use one machine to sync the ABS tree in Arch, and serve it to the rest of your house. Feel free to experiment.

Case in point: Charm at 100Mhz 16Mb

Edit: This post was polished a little bit and the image was added, after I posted it. But the raw content was written and uploaded from 100Mhz.

Occasionally I feel the need to prove that these things can actually be done with old computers, instead of just babbling on about them without any real proof. That’s bad business, and hypocritical in a way. It wouldn’t do to simply point out options withou at least showing that they work.

Charm, which I mentioned a week ago, is one of those things that I should
actually use at 100Mhz before lumping it into the “of course you can”
category. It’s one thing to condone the use of an outdated machine for
something like low-impact blogging clients, and another one to use it
outright.

So here’s the proof. This one was written up the old fashioned way, with
nano as the editor and Charm as the intermediary.

I decided to forgo WordGrinder this time, mostly because I intended for this
to be a short post and not require the time it would take to build
WordGrinder and its dependencies on a surrogate system, implant them
onto the piggybacked drive. …

Anyway, nano is perfectly capable of handling the actual chore of writing,
and this time I did myself a few favors, and added a few flags to the editor
command in my .charmrc file, to give it more of the feel of a word
processor. My editor variable is now nano -ADSWcim -r -4, but
you could adjust that to whatever you like.

There are still a few bugs that need worked out. For one thing, the
translation between nano and its word wrapping and WordPress.com and its
word mangling is going to require either (a) a little patience and
experimentation, or (b) a secondary machine to touch things up after they’re
posted. I can afford either, if I decide to continue using this machine this
way.

Which I might, actually. With the addition of a new wireless card to the
household, this machine can now live further away from the router. And the
old WPC11 wireless B adapter is plenty fast, with little more than text
files to transfer between this machine and the outer world.

And a console-only environment is fine for this. This machine will work
graphically, but there’s a considerable difference in performance, when you
consider the swapping that occurs at 16Mb RAM with X running.

A couple of other things would be nice though, and I might add them. gpm,
for one, so I can get some basic mouse controls. And elinks would be nice,
since as it is, I rely on another machine for skimming the net. I have mc
installed, and NFS support will allow me to move files around. After that,
there’s little more that this needs.

The best part of this though, is that the keyboard on this machine has a
good feel to it. It’s hard to describe, but it’s probably something you can
empathize with. It’s a little noisy, but the keys have a nice touch, and a
strong springback. It’s pleasant to type on.

Which gives me enough reason to keep it, at least for the immediate future. If I can get my hands on a little more memory and a hard drive of practical size, I see no reason to consign it to the technological afterworld.

P.S.: I should probably note that I had to edit version 1.9.1 of Charm to reacocard’s suggestions before I could upload with it. But simply moving those lines up before the try condition worked … like a charm.

Must … not … buy … another … computer …

A trip to my local recycling shop yielded another find today, a still-shrink-wrapped Corega CG-WLCB54AG2, which I believe uses the Atheros chipset and should be fairly easy to get working. I figured any card still wrapped in the box with a price that’s one-quarter of the original retailer’s sticker is probably a good find, whether or not it works with Linux.

And I spotted a nifty Thinkpad sitting by the door; this time it was a 700Mhz Celeron, which makes it another A21e, if I’m not mistaken.

I practically gnawed my own fingers off trying to keep myself from buying it outright; the asking price was a mere $40, for 192Mb and an 18Gb hard drive. Working or not, if it is another A21e, then the screen on this one might be a possible replacement for the one I already have.

But if the insides were as nice as the outsides, then scalping the screen would be a shame. Something with those specs is easily converted into a speed demon with Arch Linux, provided it’s in working shape of course.

But my arsenal is turning Thinkpad-heavy these days, and decisions like this are best decided after a night’s sleep anyway. Taking on another underdog means there would have to be some logistical issues solved — most notably proper desk space — as well as the practical role for another eight-year-old laptop.

If it were any other brand, I’d probably just shrug it off. After all, right next to it was a Fujitsu Pentium 4 laptop for only twice as much, and there’s a mint-condition 800Mhz Duron laptop in a display case for three times as much as that. Neither of those was interesting though.

I blame the little voice in my head that keeps saying, “But it’s a Thinkpad. …”

It got worse; I doubt it’ll get better

It’s been a long time since I mentioned the unfortunate computer we have at work, and it’s futile battle with Windows. I haven’t mentioned it — it’s a Hitachi Prius, something like this — because I try not to use it; for a long while it was so aggravating that I resorted to hijacking it with SliTaz.

And in the year or so since then, it’s grown slower and slower, with only more and more crudware being heaped on it. At last check, there were several calendars and scheduling programs, several PDA link clients, four or five photo transfer clients, two virus scanners and a mess of other proprietary junk all floating in the taskbar. And me of course, running the portable version of Firefox out of my documents folder.

The company contracts a technician for computer services, and after another visit today, I see that the machine is now running an adware scanner and a spyware scanner too. As you might imagine, performance is even worse. Boot times are longer, logging in takes longer. It even takes Windows five or six seconds to display a password box when you click on the user account to log in. Frightening.

The sad part is the irony: Here’s a computer that is obviously laboring under the strain of too much junk, and the solution is to add more junk.

I almost feel bad — for the machine, yes, but for Windows too. It’s been a long time since I put up with Windows, but even on my worst day I doubt I had a system as cluttered and mismanaged as this one. And I certainly never added insult to injury by swamping it with more software. I’ll admit it’s possible to run a clean and fast Windows system, but this one is definitely not one.

I’ve thought about suggesting Linux to at least take over the file-serving duties of some of the office computers. To be honest, what holds me back is fear of being relied on as the office tech person. I don’t have the time or resources (or paycheck) to do that properly, and if the company is prepared to pay the Windows guy to come in and install more crud, surely they can harness a true Linux geek somewhere locally, and give her a job.

No, I won’t be pushing Linux this time. If things continue in this downward direction, I imagine the machine will be relegated to the dustbin. Management seems to think the solution to an old, lethargic computer is to buy a new, faster one, and I’m inclined to let them think that.

After all, I might be the recipient of a perfectly good 1.3Ghz Duron.

Case in point: rtorrent slave at 100Mhz 16Mb 810Mb

You might have guessed from the last post about patching rtorrent against gcc 4.3.2, that I put Crux on the 100Mhz laptop again, and I’m giving it a run as an rtorrent slave with the same arrangement as my beat-up Thinkpad.

This is one of my four remaining test cases for outdated hardware — extremely outdated hardware — that I have been mulling over in the past few days. This time I decided to forgo the graphical environment completely and stay in a console arena, to remove as much unnecessary overhead and see how rtorrent behaves with itself as its only obstacle.

I thought perhaps the processor wouldn’t be able to keep up with that much “work,” or perhaps 16Mb would be impractical for the demands of rtorrent, even as light as it is. But according to top, the CPU is floating at around 47 percent usage and RAM is only a third filled, as it manages the Archlinux 2008.06 FTP ISO. More torrents, of course, might mean more work, but at this point a single torrent is enough for a test case.

Network speeds across the Corega FEther II PCC-TXD PCMCIA card are actually quite good — I’m peaking at around 240kbps on the down, a fraction on the up. Although that’s not a true indicator of the card’s capability, I’m satisfied that the card, the RAM and the processor are not to blame for weak download speeds.

No, the real problem I have with this arrangement is not the processor, the network card or the sparse RAM. Luckily, or maybe unluckily, the biggest impediment seems to be that hard drive. It’s too small, too slow and too noisy. With only 810Mb to work with, it’s barely enough space for the system files, let alone anything I would want to download.

And access times are hideous. Hash checks are five- to six-minute affairs, and that’s only for 138Mb or so for the Arch ISO. And the noise that leaks out of it makes it completely impractical for running overnight; the racket would keep the entire building awake.

But it works, and my original “hypothesis” of an extremely low-end machine serving as a round-the-clock torrent slave seems more practical than ever now. Putting a machine into service like this keeps it out of a landfill, power consumption is low on a laptop, and the net price for a machine like this is well under $100, plus or minus.

I probably won’t let this take over from my current torrent slave just yet, mostly because I have other plans for this machine and the busted screen on the Thinkpad is what keeps it bound as an indentured servant. But with a little luck, and if necessary, I am confident a machine like this can handle the workload.