My free time is exceptionally scarce this week, so I don’t have much to write about today. I will, however, leave you with a link that you might find interesting or useful: My Ubuntu Network, which is a social networking site with Ubuntu as its locus.

I can’t vouch for it personally, but I know that it is managed by Ms_Angel_D, who is also a moderator on the Ubuntu Forums. So I am confident you are in good hands.

In the mean time I have a few real-life projects that are monopolizing my free time, so if you will excuse me. …

It’s time for a few more console applications. I had hoped to post a few of these yesterday but real-life chores got in the way, so I had to wait a day.

I have four or five here that are all … I’m not sure what to call them, but I think “time trackers” or “time managers” might be accurate. They all have a time-punch function that can be terrifically useful for anyone who needs to watch time devoted between tasks.

Here’s the first one: worklog.

worklog is very straightforward, with an adjustable list of projects that you determine keystrokes for. Press a key to start timing a job and press it again to stop it.

You can increase or decrease time arbitrarily and enter descriptions as well. It’s probably not fair to say this, but worklog is probably what I use mentally, as the generic time tracker application.

There are a few things I don’t like about it; for one, some of the keystrokes you see — like the DEL key to quit — don’t seem to work. I have to quit by CTRL+C.

And the “projects” file has to have its details listed in reverse order, which strikes me as odd, in this day and age. Twenty-five years ago when I had to list things in reverse order on my C64 for it to look right, I just took it in stride. These days, that’s unusual. Maybe the problem is me.

Regardless, little points like that make me think worklog is a work-in-progress, and just needs a little more time to mellow.

The next is wtime.

A simple switch flag for turns on and off a counter, and another switches between projects. You have the choice of a running count for time spent, or a range of dates and total time accumulated.

It’s very simplistic when compared with some of these others, but programs like this are usually the groundwork for larger, more intricate interfaces.

It’s a little dated (last release in 2006), and it’s not real flashy, so it might not be practical unless you’re willing to incorporate it into a larger tool.

The next two are a pair of sorts. timebook and a derivative called timetrap.

 

As I understand it, timebook is python-based while timetrap is a ruby version, and they both have similar structures and functions.

From a strictly superficial standpoint, timetrap seems to have a few more options than its predecessor, but that might just be the benefit of working in the wake of another program.

Personally I see little difference between the two, so you might have to install one, try it out, then install the other and see how each one ranks.

(I notice that they share commands — they both scramble for the “t” command as their default application name — so you might have to unplug one before trying the other.)

For my money both python and ruby applications tend to bog down low-end hardware, and so if I have to make a life-and-death selection, I would probably go with timebook. To each his own though, and if you have a lot of processor power, it won’t matter.

Last but not least is punch, a/k/a punch-time-tracking on Google Code, which works atop of todo.txt, which is a list manager.

I don’t have a screenshot for that one, mostly because I had trouble getting the two to work together. For some reason there seemed to be a disagreement over what the configuration file should be called.

Judging by the examples on the home page though, it appears to work much like the others. If you already use todo.txt, this might be a natural choice for you.

And there you have it. The odd part of this little essay is that few of these are in the repositories for the two distros I usually check — Arch or Ubuntu.

worklog is in the Ubuntu repos for Dapper onward, and AUR has only timebook-hg to speak of. So in that sense, if you’re looking for some very, very easy projects to sponsor, here are a few.

Enjoy.

Time is short today and I have been wanting to make note of a few links specific to Arch Linux. If you’re already an Arch user then there are probably no big secrets here.

On the other hand, I occasionally have to look for these links again when I install a new system, and that means they’re probably best kept here, where I can find them quicker.

Probably 95 percent of the Arch screenshots you see include a nifty logo and rundown on the guts of a system. For example …

That one is Archey, which is in AUR here. Archey has a few small options available to it, but otherwise, what you see above is what it does. I should convert it to Crux. Nah.

The page in the wiki on additional repositories mentions the Arch Games repo, of which only one of the sites works for me.

I use this one as a backup, and thus far it seems to work for me.

[arch-games]
Server = http://pseudoform.org/arch-games/games/i686

Of course, you should always be skeptical of software installed from unofficial sources, etc., etc.

Another good site to remember is the Arch Rollback Machine, which can save you from a dead system in case an update creeps through that scrambles your installation.

The rollback system is discussed in full on the forums, here. There’s a lot that’s involved in rolling back your system though, so beyond that link I can’t get into too much detail.

It’s rare (for me) that an update breaks something, and Arch definitely not the only distro, in my experience, to install a broken package. But knowing how to get out of a tight spot is important for any computer user — regardless of OS.

And I’ll mention it last because of my own bias — there is a site that focuses solely on Arch Linux blogs, and it is updated fairly regularly.

archlinux.me is worth looking at once and revisiting again, if you’re the least bit interested or concerned with the distro.

No guarantees of course, as to quality or frequency of updates. Like I have mentioned in the past, I consider blogging to be at the bottom of a long list of worthless pastimes, but it has its followers.

That’s it for now. Real-life commitments are calling me. …

I probably shouldn’t get involved in discussions like this one, because they’re usually the ones that make me wonder if my ideas are out of whack.

But any thread that asks why so many people choose ugly or text-based interfaces needs at least one dissenting opinion.

I won’t waste time repeating what I said there, except to underscore that without the freedom that Linux offers, the whole planet would have a grand number of two, maybe three choices for their GUI.

Whether or not it’s ugly or out of date or text-based or pointer-based or driven by the electrodes taped to your skull … I could care less. Do what you like to your interface, because it’s yours.

The only person who has to suffer through it, is you.

And before some wag shouts it out, yes, I know, pretty is a feature. And there is nothing to be inferred in my preference for a text interface. Your way is the right way.

P.S.: You can link to an awful CDE desktop or Windows BOB if you want, but I can guarantee someone out there on the planet thinks those are quite attractive. Humans are weird that way.

It’s not all sad news around the house today though. This month has been chock full of anniversaries and milestones, and yesterday I noticed another one: the “birthday” of the Pentium I use on a daily basis.

Yep, a year ago I found a museum-quality Pentium computer in a thrift shop down the road, dropped a single 1000-yen note on the counter top and brought it home.

Since then it has supplanted just about every other machine I’ve owned in the past decade, accomplishing the same day-to-day tasks on a fraction of the power and resources, and hopefully inspiring a person or two in the process.

It’s taught me a lot about usability, function, power and efficiency, and even served as the guinea pig for one of the most gratifying experiments I personally have ever conducted with a computer.

So here’s a first-anniversary snapshot, just for the record and to preserve a memory. Ladies and gentlemen, the Fujitsu FMV-5120 NU2/W. Fourteen years old and in its prime.

Cheers, and may all your prized possessions likewise last beyond their intended lifespan.

Sometimes life just isn’t fair.

I didn’t do anything to deserve this, meaning it wasn’t dropped or smacked into a door frame or something.

I had noticed a tiny hairline crack creeping around that hinge mount there, and today when I opened the case there was a terrifying splintering noise.

 

It looks like someone stabbed it with a box cutter.

Very depressing, really. This is the machine I bought almost three years ago in a recycling shop on the other side of the island, at what seemed like a rather trivial price, for what I was getting.

At first I thought this wouldn’t affect its function, but now I’m not so sure. The hinges and screen must be torquing the motherboard or power connections, because now when I try to push in a USB drive, power drops immediately. That top picture is the last one I have with the power working alongside USB.

The smaller irony here is that I had an inkling that I might give this one away in the near future. It has a legitimate Windows ME serial number, even if that’s something of a curse.

The thought was that any of the machines I keep as “spares” could probably take over the two or three jobs this one does, and this could possibly work for someone else as a fully functional machine.

That’s just impossible now. It’s visibly damaged and behaves badly. Scarred machines don’t have much appeal, even when the price is zero yen.

I guess I’ll keep using it for as long as I can suffer to look at it, in its new, battered state. Things like that just make you feel bad though.

Here and there, where I can, I have come across some workable distros that will run on a 150Mhz Pentium with only 32Mb of memory. It’s a rarity though, and even more unusual to find one that will boot and install, in that small a space.

In fact, more than ever it seems the issue I have to confront is not a lack of processor speed or even hard drive speed, but simply memory overhead. That’s my limiting factor.

I get around it by installing from a live CD to a virtual machine, and then writing that image to the host drive with dd. (dd is quickly becoming another of my favorite tools.)

That was the case with Bonzai Linux, which I am reaching way, waaay back into the past to show off.

 

“Show off” is kind of an overstatement though. Unless you’re an old-school KDE fan or someone who also has a very low-end machine to resurrect, this is a bit plain.

As I understand it, this was one of the earliest efforts to put a complete graphical desktop on a bootable ISO, dates back as far as 2003, and is using Debian Woody as its backbone in the final release. I could be wrong on any one (or all) of those points though.

And while it couldn’t install straightaway from the ISO, it had no problem with the bait-and-switch installation style, and actually booted on the Mebius.

After that, I had a nifty full-color, proper resolution KDE 3.1 desktop, floppy access, graphical file managers, browsers, etc. Kernel is 2.4.20, and the entire business had no problem fitting into a 1Gb drive space.

On the other hand, a kernel that old lacked some of the modules I am accustomed to seeing in the 2.6.3x series, and sound was also an issue. And the screenshot you see above is much nicer than what I was actually seeing on the screen — bad artifacts, fractured dialog boxes, mouse trails and so forth. …

But it worked. It booted on 32Mb, gave a full graphical desktop in that distinct KDE style, and while definitely not perfect, it’s one of the “winners” in recent days.

So you can, if you have to, reach all the way back six or seven years in the history of Linux desktops, and occasionally come up with a working machine. Just more proof that old applications don’t die.

Not really Linux-related, but a quick thanks to Astute Reader No. 1, who sent along a great three-minute clip off of (gasp!) YouTube from a year ago or so, showing simultaneous boots on a Vista-laden PC from 2007 and an ancient floppy-driven Macintosh Classic from 1984.

Rationalize all you want, it’s still taking far longer for a vastly more powerful computer to get to a workable starting point than a lowly 16-bit floppy-driven machine.

This is the part where I usually insert a long and windy tirade about bloated software and inefficient programming and why it’s ridiculous to waste money on newer faster machines when obviously the old ones will work, if given a chance.

But I’ll spare you. You can use your imagination for that point, and even use a creaky old librarian lady voice if it makes things more amusing.

P.S.: For goodness’ sake, don’t read the comments to that video. I don’t know what it is about YouTube that attracts the weakest minds on the planet, but. …

It’s been a month now since I swapped out the hard drive in my 14-year-old Pentium for a commonplace 8Gb CF card and connector. And to be honest, I’m almost disappointed.

Because nothing has happened. Everything works just the same as a conventional hard drive, only lighter, faster, cleaner, cooler and with less stress.

I really wish there was something to report, but the whole experience started out perfectly and hasn’t skipped a beat. I regularly power on the machine, boot, sometimes disk check, continue on with the events of the day, and power off.

I read, write, save files and images. I compile new software, make updates, build kernels, troubleshoot configurations and experiment same as ever — all the while writing and reading the entire system to the card.

And there have been no problems. No hiccups, no disk errors, no transfer issues, no evident size reduction, no measurable space constriction, no mistakes, glitches, bumps, kerfuffles or rigmaroles. It’s been smooth sailing since the first power-on.

So what can I say? It’s lasted longer than I expected, and shows no signs of breaking or quitting. The rumor is false. CF cards aren’t any less or more reliable than conventional drives — and I feel qualified to make that statement, considering I’ve lost two standard drives to hardware faults in as many years.

In fact, the entire experience only makes me want to really kick one in the shins — really put it through the wringer, and see what happens to it. Something beyond day-to-day use, and more in the realm of intense, sustained abuse.

So I’ve ordered another one, as well as another adapter, and I’m going to hunt down something that is designed to kill hard drives — some application that will simply thrash away at disk space and force the darned thing to quit.

I’m going to start the thing and let it run until it freezes, catches fire or collapses in a puddle of tears, begging for mercy.

It’s all purely in the name of science, of course. I’ve already exploded the myth sufficiently to prove in my mind that any computer I salvage or keep in the next decade will be fitted with similar connectors and cards.

But this is no longer about just using an unconventional solution for an everyday tool, or about saving a little power and perhaps gaining a tiny sliver of speed. It’s not a gimmick or a stunt now. This is a mission. This is war. This is … SCIENCE!

The leftover Pentium I bought about ten days ago has thrown me for a loop … mostly because, it’s just not a leftover Pentium.

Originally I had planned to scavenge the machine, stealing the memory and possibly the CD drive for use in this one. That might seem like overkill, but with the market price for a used stick of PC66 laptop memory hovering around US$1.50 plus shipping, it just makes sense.

After all, the whole machine cost me about US$10, and I’d pay that much — if not more — for that single stick of antique computer memory. Why buy the milk when you can have the whole cow for the same price?

As luck would have it though, it’s a viable machine in its own right. After I cleaned away the dirt and grime from the screen, it turned out as clean and clear as either of the other two Pentium machines I own, save a faint bleached area in the upper left corner.

That screen is also slightly bigger than its predecessor’s — probably something like 12″ as opposed to 11.1″ — which means the porthole screen I have learned to ignore is a non-issue with the new one.

And I have desperately lusted after a CDROM for the older machine. For every time I have had to pull the drive, connect it to another computer, compile or troubleshoot, then swap it back again to continue … a simple live CD would have saved me hours.

That CDROM, as I have discovered, works fine and is quite speedy when compared to the one in this one. I still haven’t managed to make it boot in the older one, but otherwise it works as it should.

Add to that a battery that lasts two hours and recharges in the same amount of time, a more-than-adequate 32Mb of memory and a fully working keyboard, and you have the machine I wanted very badly … about two years ago.

Aye, there’s the rub. I’ve already got a low-speed machine in the house, as well as a fractionally faster one with a bootable CD drive, bootable floppy, the same amount of memory, a 17-megahertz edge in processor power, a working battery, stereo sound, the same video card, similar physical condition, easy access to the interior, and the immeasurable bonus and convenience of a single, solitary, antiquated USB port.

You wouldn’t believe how often I use that USB port.

And so that’s the spot I find myself in these days: I am the owner of not one, not two, but three low-end excellent condition antique computers — any one of which could easily keep me occupied for years to come.

I can’t bear to throw it out, because it’s in good shape. Nobody but me (and maybe you) could possibly find it useful, and even if I have dozens of uses for it, the restraining factor is time.

So I imagine I’ll put it on hold for a little while. At some point I will probably need or want another low-, low-end computer for testing or something, and it will come in handy.

In the mean time, I have a few other things that need my attention. …

I’m still learning about dd. It took me a while to discover it, but now I use it on a daily basis (well, maybe not quite ) to clone systems, backup entire drives, get visual snapshots of the data on a disk or to scramble the contents of a floppy or USB drive.

A couple of days ago I got a 60Gb hand-me-down hard drive that I didn’t want to look at, and arbitrarily plugged it into an always-on machine and put it to work with time dd if=/dev/urandom of=/dev/sda.

And as promised, it dutifully started dumping random information into the drive, churning away for 10 minutes, 20 minutes, an hour. …

By this point I was starting to itch to use the drive. But it was time to take care of some real-life issues, I let it run while I left the house.

When I came home at the end of the day I expected to see a report, but it was still running. I didn’t have time to fiddle with it, so again, I left it run, this time overnight.

In the morning, it was still going. And at the end of the day yesterday, it was still going. …

And this morning I decided to arbitrarily cut things short. I suspect that over USB1.1 I probably should have employed different flags or block sizes, to avoid a two-day session writing out random nonsense to a hard drive.

But I definitely blame myself for this little inconvenience — after all, I should have thought about what was happening: the transfer of 60Gb of information over USB1.1.

I’m no stranger to slow speeds over USB1.1, and so the little alarm bells should have gone off after only a few minutes. Even USB2.0 would take a while, for something of that size.

In any case, I have learned my lesson. If you want to blank a drive with dd, for goodness sake don’t do it over a slow USB connection.

Remember 3ddesktop? Before Compiz was adopted as the messiah of the Linux desktop experience, 3ddesktop was the way cool kids spun their work environments and dazzled their Windows-using friends.

And it was pretty cool — it never was nearly the catalog of intricate bells and whistles that Compiz is, but it did a decent job in the eye candy department.

Of course, it did require a little video muscle to use. But considering its last update was in 2005, you could — and still can — get away with running it on a single-core machine with a ground-level video card that has a little acceleration to it. Even something as underpowered as this should do it.

I do not, however, recommend it on a 14-year-old computer.

Don’t ask me why I tried, because I don’t know why I tried. Except that it was vaguely amusing to try it … and in actuality, it did work. My Openbox windows zoomed away, the numbered labels faded in and out, the workspaces spun in the direction I asked … over the course of about 15 minutes, that is.

I can’t prove it because I don’t have a screenshot. I don’t have a screenshot because it slowed the system down so much that I had to pull the power to get it to stop. You’ll have to take my word for it: It worked.

Completely unusable, terrifically impractical, but functional … in the very strictest sense of the word.

What other particularly lamebrained tricks have I tried lately on a Pentium laptop? Well, seeing 3ddesktop in action (I laugh as I type that) suggested maybe xcompmgr would work.

That was an exceptionally dumb idea, although it is possible that I misconfigured it, and inadvertently caused its demise.

While 3ddesktop could conceivably be used to switch between workspaces (if I was willing to wait about half an hour to do it), xcompmgr caused a two-second hiccup, followed by a cataclysmic X crash to the terminal prompt.

No, I didn’t look at the logs — I rarely look at the logs and particularly not this time. I already know what the logs said; they said, “Hey, don’t run a composite manager on a 150Mhz computer.”

Oh well. One can dream. There are things that you can do, but just shouldn’t. But there’s no harm in trying.

Time is short today, so I have only a brief list of sites that mention software alternatives.

Some of these are explicitly aimed at life without X, while others are concerned mostly with making a transition between Windows and Linux.

Regardless of their focus, they’re fun to browse when you want ideas for new software to try, or if you need an analogue for something you already use.

Jared’s CLI apps list	This isn’t the first time I’ve mentioned this page, but it’s still my favorite list of CLI applications. That’s mostly because it doesn’t pretend to be anything more than that: a list of CLI applications. It’s perfect for scouting a particular task and finding a console solution. I’ve scraped through the list dozens of times, and I still keep finding new stuff. Thanks, Jared.
cli-apps.org	I mention this out of a sense of obligation; it’s one of the first places I used to look when I started to prefer console apps over GUI software. These days though, it seems less useful than it once did. There are a few gems here and there, but you have to really pick through the list to find them. And ironically, it’s not particularly comfortable for a text browser.
Converting to Open Source	Laura Michaels has an interesting list of applications available for people thinking of switching. It’s a little out of date (okay, more than a little), but I find that to be useful: It doesn’t list a lot of the bottom-heavy frontrunner applications that are commonplace today. It’s not all terminal programs, but it’s definitely worth skimming at least once.
Slax software list	As if there wasn’t enough already to make Slax a miracle sent from heaven, you can actually filter its software database for applications that run at the console. Be careful when you do that though — you’re guaranteed hours upon hours of wading through lists of programs that you can’t wait to try out. Best save this one for a rainy day.
automatisch.cc’s text mode software list	In German, but that shouldn’t dissuade you from using it as a source of software ideas. Neatly organized and categorized, easy to skim and fun to explore. Be sure to look though the “Spiele und Spass” (fun and games) section. And if the language proves to be a barrier, ask Google for help.
Life in Text Mode	Over at aperiodic.net is a fun list of practical software used by someone like me, who preferred the prompt to the mouse. It’s a few years old, but I would bet that 90 percent of the applications listed there are still actively developed — which means they’re not only mainstream, but they’re popular for a reason. Technically the writer was an ion user, but that’s nothing to quibble over … particularly so long as I am using Musca on two machines.
osalt.com	I suppose no list would be complete without osalt.com, which I must say I never used personally but has been a godsend to two or three other people who’ve switched under my tutelage. Whether or not it is useful to you remains to be seen. It’s definitely not focused on the command line, but you shouldn’t let that dissuade you from checking it out.

That is about all I have now. There are dozens more out there; feel free to suggest some more.

I made a little progress today, with the problem of console music players at very low processor speeds. The house favorite, moc, has a tendency to stutter on machines slower than about 200Mhz (that might vary from machine to machine and distro to distro) with standard-quality sound files.

By all means it should be possible to play mp3 or ogg files on machines far slower than 150Mhz, but for whatever reason, the machine slows to a sputtering crawl, CPU use sits solidly at 100 percent, sound quality drops to a hideous level and the entire experience is an unqualified failure.

Today, during a brief break, I rebuilt moc 2.5.0-alpha4 to remove absolutely everything I don’t use — unwanted codecs, unneeded support flags, you name it — and leaving only things I knew I would need for either my own 100-percent ogg collection, or streaming music channels.

I think it made a difference. There is still a measure of stuttering on startup, and when a new file is started (which I assume is lag caused by some kind of caching process).

But that stutter only lasts a half a second or a little more on 44Khz VBR ogg files, which is a vast improvement over the continual chirping I was getting with the default configuration of moc 2.4.4 for Crux.

It’s still not perfect — CPU use is still in the 85-100 percent range, any interaction with the machine causes a skip or two, and outside interference (like the normal power off for the screen) also causes a hiccup.

But it seems to recover much more quickly, I don’t have to drop out of the interface to listen to a song, and it’s relatively usable. And listenable, if that’s a word.

For the record, this is the Pkgfile I used to do this; if you’re also a Cruxian you could give this a try. Arch users could also adjust this to their liking. Note that this pulls libsndfile and adds flac — those are personal preferences.

# Description: Console audio player.
# URL: http://moc.daper.net/
# Maintainer:
# Packager:
# Depends on: curl flac libvorbis libid3tag libmad

name=moc
version=2.5.0-alpha4
release=1
source=(ftp://ftp.daper.net/pub/soft/$name/unstable/$name-$version.tar.bz2)

build() {
	cd $name-$version

	./configure \
	--prefix=/usr \
	--mandir=/usr/man \
	--with-alsa \
	--with-curl \
	--with-flac \
	--with-mp3 \
	--with-ncurses \
	--with-vorbis \
	--without-aac \
	--without-ffmpeg \
	--without-jack \
	--without-modplug \
	--without-musepack \
	--without-ncursesw \
	--without-oss \
	--without-rcc \
	--without-samplerate \
	--without-sidplay2 \
	--without-sndfile \
	--without-speex	\
	--without-timidity \
	--without-wavpack \
	--disable-nls \
	--disable-debug

	make
	make DESTDIR=$PKG install
	install -D -m 0644 -t $PKG/usr/share/moc/ config.example keymap.example
	rm -rf $PKG/usr/share/doc
}

Let me know if you have better luck, or if you can trim back the player itself any further. In the mean time, I’ll be trying to force the BIOS power management to stop interrupting my music when the system is on battery.

Sometimes I’m not really sure what I am doing, aside from trying to break things. On a weird thought the other day, I dug into the /etc/inittab file on my one machine running Arch Linux, and substituted Midnight Commander for the first agetty command there.

After all, you can swap that out for mingetty or *getty or any other “login manager,” so why not a regular application like I normally use? Couldn’t that take the place of an autostart from the bash prompt?

Well, I’m not really sure what I was expecting to happen, but what I got was an instance of mc running in tty1, and because I had tagged that line with the “respawn” flag, it simply rolled back into place every time I tried to quit out of it.

How quaint, I thought. A permanent file manager with the press of ALT+F1. But it was running as root, and so my next thought was to trigger mc the same way I trigger X at boot, with this line.

c3:2345:respawn:/bin/su kmandla -l -c "/bin/bash --login -c /usr/bin/mc"

I put that in c3 and commented out c1, because mc was landing in tty1 no matter which line started it. And because I usually only run two tty’s at a time anyway.

And got roughly the right results: mc running as the regular user in tty1. Every time I tried to exit, it simply started up again.

How about two? I thought. But adding another program just created havoc. If I added htop and mc, they both tried to compete for that first “tty”, and just made a mess out of the screen.

Well, I thought, the obvious solution here is to start screen and then let both of them live inside that marvelous program.

But screen wasn’t having any of that business, crashing rather loudly, rather quickly and quite repeatedly — which triggered the respawn warning and an admonishment from the system.

I tried swapping “respawn” for both “wait” and “once,” but then the only message was a refusal from screen — that it “couldn’t find /dev/console,” and was giving up.

At which point I gave up as well. I don’t know what I intended to achieve with this, and I don’t even know what I could expect to achieve with it. But perhaps sometime in the future this will come in handy.

Which is why I make a note of it here. Because that’s what this blog is for.

August seems to be the month for milestones — and anniversaries — so here’s another one.

It’s been about a year and a half since the 1,000,000th visitor, and I wasn’t expecting to cross this mark for another few weeks. But here’s the marker, with the added bonus of being a palindrome. Because just No. 2,000,000 would be ordinary and boring.

Thanks again for visiting, and cheers if you find the site useful.

–K.Mandla

As much as I tout console applications, people always seem to complain of very few full-featured word processors for the Linux command line. That might be an issue of perspective though.

I have mentioned WordGrinder in the past, which is a good substitute but most people dismiss because they want something with more features. And WordGrinder hasn’t seen any love in almost two years, so it may not be going anywhere.

For my own part, I use vim with word-wrapping enabled. That’s what I’m typing on right now.

But for all its power and eccentricities, that usually gets shouted down as “not a real word processor” either. Most other text editors suffer the same abuse — just not as complete as is required.

That’s the real issue here: Each person is going to want something different out of a word processor. So let’s face it: If this is what you want, this is what you want.

 

Yes, you can still download the good old Word 5.5 from Microsoft, free of charge, and run it under DOSBox. It’s got all the bells and whistles you probably wanted, can open early versions of its own proprietary file format (I really doubt docx will do the trick here), has mouse support, is ugly as sin and probably endears you to the evil empire as soon as you click on the download link.

But if it’s a word processor you want, and you want a text interface, and you want it to do all the little flashy blinky things that your imaginary word processor does … then yes, I suppose you could always drop back and punt (is that the expression?) and use this to console your console affections.

It doesn’t do the trick for me though: It requires X, all its trappings, plus a hefty measure of graphical support to draw what is essentially a terminal box on the screen.

Only one computer in the house has the power to handle all the underpinnings it would take to use Word 5.5, and then I would suffer a guilty conscience too. Just to read a .doc file.

No, for the time being I shall continue to use antiword and vim together to read or edit Word files, and I will leave the eternal search for the holy grail of Linux console word processors to other people. I am satisfied with what is available now.

P.S.: If you want to use Word 5.5 in DOSBox, install DOSBox first, download the file above and trigger DOSBox from an emulator with dosbox Wd55_ben.exe.

Word will decompress itself (answer yes to any overwritten files), and then you can enter SETUP.EXE from the command line. Follow the installation wizard, enter WORD.EXE and voila! a whole new world of word processing glee will ensue!

With so many computers around the house and not really enough things to do with them, you’d think I would make a point of not bringing home another leftover piece of junk.

Unless it’s something I can use as parts, or to improve upon the machines I already have.

That’s what I thought I was doing when I found a Fujitsu NU/13D, a rather banged-up 133Mhz Pentium machine with 64Mb of memory in it, a CDROM but no hard drive.

Ideally, the plan was to scalp whatever was usable — memory and CDROM — and use it in my own Fujitsu Pentium. Alas, it was not to be … in part.

The machine came out of a junk bin in a recycling shop, and some wag had already scooped the memory out of it, or it never had any additional memory to start with. Bummer.

So the CDROM was the only viable transplant, and I say that not having torn apart the machine yet to see if the remaining 32Mb reported by the BIOS is removable. The last Fujitsu-series Pentium I tore apart had the memory fused to the motherboard.

Interestingly, the CDROM is accessible from the operating system and BIOS, but the option to boot from it doesn’t seem to work. It’s possible that it is not completely compatible; the machine is actually a full year older than the one I type on now.

And oddly, it is not an unattractive computer. It’s rough around the edges and needed a vigorous cleaning, but all the parts appear to work and the screen is in good shape. It’s a tiny bit bigger than the one I have now, too.

But the guts are not appealing to me — it also has a dreaded Trident video card — and since the Mebius has USB ports, this new machine is not likely to take over any time soon.

Ironically, I can boot to something like the final release of Damn Small Linux, get a full screen, full color, full resolution desktop, connect to the wireless network with a leftover orinoco/agere wireless card, and all that without a hard drive … and the battery will last an hour and a half.

Too bad that battery is not compatible with the machine I use now though. It will insert, but it can’t draw power off it, and I see where the “model number” on the battery is different. Probably different connections. Oh well.

I also found a rather quaint Corega WLCB54GL2 PCMCIA wireless card, and it apparently is working … sort of. It’s RT61-driven, and it’s been a really, really long time since I fought with an RT61 card.

I can see where the drivers are available in the kernel, but for some reason my kernels can never find the firmware need to run the things. Technically it works (I can get online and surf in Arch Linux) just not when I try to do it myself.

The last thing I noticed was a creepy looking laptop of some sorts: something called a PCsel L7 Avie, if I remember the name right. The screen was minuscule and the size of the thing was suspicious in its smallness.

So I might have been looking at a true antique — maybe a 386 or even 286. I’m sorry to say I didn’t have enough money to take home both that and the Fujitsu, so I left it there.

Of course if I go back now, it’ll be gone. In the wild, wild world of leftover computer junk, you can’t pause to think things over. You gotta move quick. …

Why in the world anyone would want Linux to look like Windows is beyond me. Particularly Windows Classic — that staid old theme that came bundled with Windows XP and attempted to look like the old Windows 2000 desktop.

And yet, thanks to the WordPress.com backend (credit where credit is due ), I can tell you with half shock and half embarrassment that the screenshots that get the most traffic are ones of a Windows Classic theme knockoff I created about a year ago. And still fine-tune now and again.

It’s ugly, it’s boring, it’s dull and it’s hackneyed. But it’s also amazingly fast, light as air and easy to set up, given you have a few configurations and about an hour of your time.

I’ve put this on everything from Pentium Classics to dual core Intel machines and without fail, it runs quick and light and never disappoints. I even had a friend over to my house about a week ago, and I was asked when I had started using Windows again.

So it must be a little convincing, at least. I’ve built this in Arch Linux, Crux Linux, Ubuntu, Debian … and if there are others out there with the same software available, I’m sure it can be done on them too.

Linux is beautiful and clean and fast and creative — just about everything Windows isn’t. So try it if you must — it’s not that great and it’ll probably be disappointing, but so was Windows. Just don’t say I didn’t warn you.

P.S.: I do not suggest using this as a trick to push someone into using Linux. Convert through desire, not through subterfuge, friends. …

This is one of those things that I will probably be looking for again in the future, no matter how lame it seems right now.

I like to keep local copies of the source code for the software I have on Crux systems, just because if something breaks and I am not online, then it helps to get things going again. It’s also useful if network speeds are slow or if there’s a problem getting a particular source package with the proper checksum.

On the other hand, that tends to take up a lot of space, particularly if there’s a large library or compile-time dependency involved. ocaml, for example, is a gargantuan beast that’s only really necessary to compile wyrd. Once it’s been built, I don’t need ocaml ever again.

So to save space I sometimes have to remove source packages (which can be neatly done with prt-utils’ prtwash -a -s command), but it makes me itchy.

So I decided today to get all the source packages back from the applications I’d installed and then cleared out, as a precautionary measure. pkgmk has a -do flag, which just gets the package but doesn’t do anything with it.

But I don’t think you can give pkgmk the name of a program to build; it has to be executed from the port directory, where it reads the Pkgfile and goes to work.

Now prt-get has a path command, which spits out the full path of a package, and that means I can cd into a path‘d directory and issue the pkgmk -do command.

If I can get a proper list of all the packages on the system, that is. prt-get to the rescue again, with the wonderfully sparse listinst command. Ergo:

for i in `prt-get listinst` ; do cd `prt-get path $i` ; pkgmk -do ; done

Not much in the way of error checking. Definitely not idiot-proof. And it could, I suppose, stand to save a little bandwidth if the package is already on hand and passes an md5sum check.

But those are embellishments. Flair! Bloat!

Anyway, that’s probably the dumbest thing I’ve come up with for a while. Watch: This’ll be the most frequent page I hit over the next year or so. This and the page for setting locales. …

Memory seems to be on my mind more than usual these days. That probably started with the myth about more memory arbitrarily improving system speed, and continued with the purchase of a gargantuan chunk of memory around the same time. And then the issue resurfaced yesterday, with an entire Openbox desktop riding on a speck no bigger than 12Mb.

I know the whole “free memory is wasted memory” argument, and in principle I agree.

But there’s a side of me that says large chunks of available memory are not an excuse for overweight software. I’m not a coder so I probably shouldn’t complain, but just because your pants are a little loose doesn’t mean you can overeat.

And really, the logic of that statement doesn’t suggest you should make an effort to use that space. It suggests you should take the extra memory out of your computer and give it to a friend. If you bought it and don’t use it, then your money went to nothing.

So … “free memory is wasted money?” You heard it here first.

I mean no offense. If you’re not using that memory, take heart: I’m not using mine either. Even this, an Arch system chrooted into a Crux system on USB and compiling mesa3d, is only using about 7-8 percent of the total memory available to the system.

And unless I’m mistaken, most of the results written in the build process will probably held in memory before they’re dumped to the USB disk en masse. So it might be safe to say usage is a wee bit higher there because of cached changes that will need flushed. I might be wrong though; htop might not make that distinction.

But it’s all hairsplitting really. Either you have enough memory or you don’t, or you have too much or you don’t. You’re the one who gets to decide which is true and what’s best for you. You are free to stack memory chips in your machine like so many slices of bread, and complain that it’s just not enough.

On the other hand, if anyone feels crazy and wants to yank a stick of PC66 from a laptop, I’d be happy to put it to work. …

I ran into a bug the yesterday, while I was building the Crux machine with Openbox on it.

Since I have been compiling everything off that machine and then syncing the ports tree over USB, I discovered a little quirk with prt-get and/or pkgadd regarding prebuilt packages. The easiest way to explain it is to show it.

bash-4.1# prt-get depinst alpine
prt-get: installing /usr/ports/local/alpine
=======> Package '/usr/ports/local/alpine/alpine#2.00-1.pkg.tar.gz' is up to date.
prt-get: installing alpine 2.00-1
pkgadd: could not install usr/bin/rpload: Write failed
pkgadd: could not install usr/man/man1/pilot.1.gz: Write failed
pkgadd: could not install usr/man/man1/rpdump.1.gz: Write failed
pkgadd: could not install usr/man/man1/rpload.1.gz: Write failed
pkgadd: could not install usr/man/man1/alpine.1.gz: Write failed
pkgadd: could not install usr/man/man1/pico.1.gz: Write failed
/sbin/ldconfig: Writing of cache data failed: No space left on device

-- Packages installed
alpine

Obviously alpine isn’t installed. pkgadd ran out of space on the drive, and in spite of displaying errors, it’s either returning a “success” code or prt-get is displaying the “success” message. If memory serves, this really only happens with precompiled packages.

I posted a bug here, and then Johannes Winkelmann suggested mentioning it in connection with pkgadd, since prt-get really just reports what pkgadd tells it.

I have not been lax in testing distros with the Mebius, but it is becoming rare to find a system that will start up effectively on 32Mb of memory, let alone install to the disk.

But I do have another miracle of modern science to show: an i586-flavor Crux system running Openbox and Xorg 7.4′s server 1.8.2 on a measly 12Mb of memory, no swap, after a cold boot.

The python memory script I mentioned a year ago confirms that, although it does put usage closer to 14Mb. I never know if I should be mentally subtracting for the space taken up to run it under python.

No matter. That’s not what is important; what’s important is that I thought only Debian could pull off this stunt, but now there are two contenders.

Memory usage is definitely lower in this rendition than in Debian, and start times from Grub to the desktop are under 16 seconds for a 150Mhz machine … with a somewhat quicker hard drive in it, so don’t tout that. Not bad at all, considering some of the speediest Arch machines I have are doing the same.

But it’s also important to note that I build Crux systems with kernels so sparse you can drive a car through them, and without an initramfs, etc., to wait on, things are considerably faster on the startup.

The standard Xorg trident driver was a loss, as was the kernel’s tridentfb module in the 2.6.35.1 kernel. With both the Xorg xvesa and fbdev drivers installed I get an acceptable 16-bit 800×600 graphical desktop.

And it’s not as much of a memory hog as I usually make it out to be. In both screenshots you can see X squished into less than 6Mb of space, which isn’t as good as this was, but it’s still considerable.

Perhaps that is another bonus to using older computers — considerably smaller demands on X.

Openbox is running the desktop in those screenshots too, and while that’s no miracle, it is amazing to me that GTK2 applications like Leafpad or gcolor2 or even obconf run without undue hassle. Yes, everything is still ugly slow, just because 150Mhz is ugly slow. But at least it’s not as bad as GTK2 was at 16Mb.

And because someone is going to ask, here it is:

Yeah, it took me almost half an hour to get that screenshot, so enjoy it. And the screen artifacts are there because it takes 20-25 seconds for a redraw for Firefox, with continuous swapping to the disk. I’d have to time-delay scrot by about two minutes to get rid of that.

For practical use though, I think the standard array of console programs inside rxvt-unicode’s daemon would be an improvement. And maybe dmenu and Musca.

Regardless, this is quite remarkable in its current form. I will continue to sift through some of the other “lightweight” distros and see what I can find, but sometimes it’s just a better idea to build it yourself.

P.S.: Sound is still screwy though. …