This might not be of interest to you, but to me, it’s a miracle of modern science.

How KolibriOS squeezes all that into 1.44Mb is beyond mortal comprehension. And it’s not just that there’s a blinking cursor attached to a terminal somewhere, but an entire graphical system, complete with notepads, system monitors, games, utilities and more nifty doodads than you can shake a stick at. The mind boggles.

Like anything it’s dependent upon hardware, but you’re looking at the same 120Mhz Pentium I use on a daily basis with Debian against the framebuffer. Run-of-the-mill it is not.

And wouldn’t you know it, the touchpad is perfect (in fact, better than Linux, since it doesn’t have X’s odd tracking behavior), keymap is … well, it’s a Japanese keyset, so I am forgiving in that department … video is quick and responsive, powerdown is lightning fast (even if startup is rather slow, coming off floppy of course), and even the conventional PC speaker (you do remember the chirpy PC speaker, don’t you?) works fine. I can see where there is support for SoundBlaster cards, but to be honest I didn’t try setting it up. That might even work, you never can tell.

Hardware is going to be where it falls down too, of course. I don’t know how much it can do with network cards, and add to that the need for PCMCIA support, and add to that the need for wireless support, and short of a standard desktop PCI network card I don’t how useful (in a conventional, I-must-connect-to-the-Internet-or-I-will-go-into-withdrawal sense) it can be.

On a standalone offline machine I would endorse this in a heartbeat; on an online machine that has whatever networking hardware it can do, I would insist upon it. This is a great, full-blown operating system with a horde of additional goodies, and at the same time it’s a marvel to watch in action and prettier than most ultralight distributions based on other software. Granted, it’s not Linux, but with something this light, this functional and this cute, how can you complain?

Against my better judgement, I am still poking around with the 560e, but with not much more to report than a few botched attempts to install Puppy Linux, alongside a few botched attempts to boot Puppy Linux.

I can’t account for why Puppy wouldn’t boot at 166Mhz, and I’m fairly sure it wasn’t the size of the initrd this time. But after a blinking cursor that simply pulsed at me for about five minutes, I decided there wasn’t anything else to be learned.

I certainly don’t hold it against Puppy though — now that is a fine piece of ultralight software. In it’s vanilla form (which is anything but vanilla) it can run at a decent pace on machines as slow as 550Mhz or slower, and requires less than 256Mb to run completely from memory. It looks good, it sets itself up well, and it’s a healthy mix of speed and function.

Between Puppy Linux and Slitaz your low-end hardware needs — provided they can struggle to a graphical desktop — are probably covered. I know there are other options out there, but if you have only two blank CDs and don’t want to waste a lot of bandwidth on distros with vague aspirations and little to show for them, those are the two I’d suggest.

In the mean time I’m going to inspect a couple other low-end distributions, and see if they have any luck getting started, and then see if they have any luck bringing up a graphical environment. I know that even if X rears its ugly head at 166Mhz it will be a disappointment, but I have to keep chasing this one for some reason. Don’t ask me why.

A lot of well-meaning people dumped their leftovers on me when I mentioned I was using a machine with a floppy drive, and had use for some spares. The things are like coat hangers now though — I have about twice as many as I wanted, and 10 times more than I need.

I also don’t really want to know what was on the floppy before it became mine, so I scrounged around a bit and found this as a command to overwrite the disk, until I find time to actually use it. As an alternative to the shred command. …

dd if=/dev/urandom of=/dev/fd0

The drive assignment is for Debian there, so it might be different for your distro. And changing the destination assignment will work for a USB drive or something else too. My primary school maths teacher taught us that we should always check our work, so …

dd if=/dev/fd0 count=1 | hexdump -C

That gives you a quick look at the earliest part of the floppy, so you can check and make sure what’s there is more or less unreadable. It’s not terrifically secure method or proof against forensics efforts, but neither of those is really a concern for me.

Since I nailed down a way to encrypt files before transferring them over the Internet to a family member, I have been considering locking up a lot of the personal files I have on hand, in case they are lost or stolen. There are quite a few though, and the time it takes to step through the encryption process makes it inconvenient, to say the least.

gpg has a batch mode though, and splicing together the loop from this command and the encryption sequence from this command, plus a little help from gpg man page and elsewhere, I cobbled this together as a one-liner that appears to do the trick.

for nam in *.doc ; do echo MyPassword | gpg --batch -c --force-mdc --passphrase-fd 0 $nam ; done

The -c flag is the same as the --symmetric option, and the --passphrase-fd 0 flag accepts the password from whatever I type after entering the command … except that the echo fills that in for me. The --force-mdc option is only to avoid a warning message on the receiving end when it is decrypted, so you can omit that if you like.

I suppose it’s worth mentioning that I used detox to clean the file names a little bit beforehand; otherwise, spaces or oddball characters can interfere with the encryption command and cause the loop to halt. If you can improve upon this, by all means please let me know. I am well aware of my limitations as a script writer.

My “newfound” philosophy regarding leftover parts is taking a sideways step these days, and making me reassess the less-than-a-month-old-to-me 560e I tinker with. I’m starting to feel like maybe this is one that’s worth releasing back into the wild, to find its own way.

Truth is, after a month of working with it, I can’t help but feel like it has shortcomings — a lot of shortcomings. Probably the biggest and most encumbering is simply the lack of any way to get a system on to it, without yanking out the hard drive or relying on a network connection (which of course, would require an installed system). No CD drive, no floppy that works (I’ve tried four that will connect, but none will read a disk) and short of hunting down a PCMCIA-driven CDROM (there’s an expression about “hen’s teeth” I think I could use here) and then still wondering if it would be compatible, it seems I have only one option for installing or handling hardware.

And this particular machine isn’t exactly flexible in that department either. Getting to the hard drive requires removing 14 screws, or at least about nine of those 14 and peeling back the upper plastic tray. I used to be annoyed to have to pull out a drive, plop it into a modular tray and jack it into my old Inspiron, but that was a dream compared to pulling the hard drive out of this.

I have other complaints besides just technical-unfriendliness and limited inroads for installation. Thus far, I’ve tried three different releases of Debian, one of Ubuntu, one of Slitaz and even put Windows 2000 on the machine (a lot of good that did me … Win2K wouldn’t even start), and not a single operating system has been able to show me a graphical environment. Even the framebuffer, which is usually something that I can handle myself without needing help from well-orchestrated distros like Ubuntu or Debian, or magical ones like Slitaz, can’t get past 80×60, and most crash and burn violently under X.

It’s not only frustrating, it leads me to wonder if there is some sort of minor fault in the hardware, if nobody can get something working. If something works in one distro but not another, I usually put that on my to-do list as a future challenge. But this is something no one can handle, and that has me eyeing the computer itself suspiciously. And honestly this wouldn’t be the first time something didn’t work quite “right” in it.

This isn’t an issue of function — I have a long list of things to do with a computer like this, first choice being to park it near the router, drop in a 120Gb hard drive and a halfway-decent network card, and let it seed distros throughout its remaining life. But again, I feel like a somewhat-useful 12-year-old semi-inconvenient computer isn’t much better than a somewhat-useful 8-year-old semiworking network card.

Especially because there are more options of its calibre on hand. Today at the recycling shop I saw another ten-dollar-wonder … a 133Mhz NEC Pentium, and that one with 32Mb in it and a CDROM as well. What a luxury. I didn’t ask about the model number, but I at that price I can take a chance and maybe pluck a winner from the display case. …

A while back I remember seeing news around the ‘net about Linus Torvalds voicing concern over the growing size of the kernel. Things like that are usually non-issues for me and I think they are for most end-users, but it’s the first thing I thought of when I put Ubuntu onto a 2Gb 4200rpm drive and dropped it into a Pentium with 32Mb of memory in it.

For the longest time now, my mental limbo-pole for Ubuntu on any computer has been 32Mb: Without 32Mb in the machine, the installer program twitched and flailed uncontrollably until you finally took it off life support and cut the power. You could, conceivably run Ubuntu on a machine with less memory than that, although dipping much lower — even by just 8Mb or so — left you in dangerous territory.

Or so I thought. I was pleased to find the random 16Mb stick of PC66 at the bottom of a box in my local recycling shop last week, and after a 12-hour marathon of memtest, it’s showing no defects whatsoever. But the aforementioned 2Gb hard drive with a clean installation of Ubuntu on it refused to start all the same. “The initrd is too big,” it said, quite politely.

I see elsewhere on the Internet where BIOS settings can come into play, but this time it might be that the initrd is just too big. How big can it be? I thought, and transplanted the drive (again … swapping drives is the story of my life) in an effort to find out. And the answer was 40Mb.

Good grief. I must be looking at that wrong. Discrepancies like that can only be explained as some mistake of mine. In any case, the error message was telling the truth. That is too big.

Now the size of a stock Linux kernel and the size of the initrd in a vanilla installation of Ubuntu 9.10 are not necessarily related, but I could swear this was never a problem before now. I am more-or-less certain that I have installed minimal Ubuntu systems on computers with only 32Mb of memory — some within the past couple of years — and they started up fine. And Debian runs without complaint on the machine, although I haven’t needed to check the size of the initrd in Debian, so it might be different. (It appears to be less than 8Mb for initrd.img-2.6.32-trunk-486.)

I suppose weight gain is the only excuse. Forty megabytes is considerable when your world is topped off by a 550Mhz Celeron, and no machine has more than 192Mb. But this world never has a need for more than about 24 of those 192Mb at any given time … unless of course, you’re trying to start up Ubuntu.

I’ll have to scrape around a little more and see if there is any way to carve down that 40Mb number, and maybe actually get the system working without having to swap memory chips as well as hard drives. I don’t hold out much hope though … 40Mb might be a stumbling block for a beat-up leftover 166Mhz Thinkpad, but to anyone else who’s not living in 1998, 40Mb here or there is nothing to voice concern over. Unless you are Linus.

I mentioned a script yesterday, so I’ll mention another one today — another sort of “download manager” for the console. This isn’t nearly as feature-ful as fttps, but since it approaches the issue in a concise and straightforward way, I thought it worth bringing to attention.

wget-queue.pl claims to be an offshoot of a bash script called wget-queue.sh, but I haven’t had much luck in tracking that down, unless this is what it means. It works in much the same way as I originally envisioned when I thought I was coming up with an original idea, and probably if I had enough skill to put together a program (which I don’t) it would look and behave in the same way as wget-queue.pl.

I’ll let you dig around and see how it works; if it were me I would plant this in a directory somewhere, set up cron to execute it once an hour or so, and keep the list of programs to download somewhere in your home directory. I adjusted it slightly for my system, so that it keeps a “session” directory where the logs and settings are stored, and a “watch” directory where I can manage the list of files to download. I wanted the style to mimic rtorrent, if you must know. I also added an -nv flag to the actual download command, because I foresaw the log file getting rather big.

If I must be terrifically honest, I think blice’s fttps is still a step above this even if it never fully matured. Even in its unfulfilled state fttps has a few more controls and features than wget-queue.pl (and wget-queue.sh, if we can count that one) and while it is worthy of some refinements, I’ll probably stick with it on my machines. The perl script is worth investigating though, if you are curious and capable of tuning it.

I only have a minute or two today, so I’ll just mention that I found this perl script that supposedly presets the used modules in a kernel configuration, which I hope will be useful in arranging custom kernels between Debian and Crux.

I still have it in my mind that I want to convert this entire system to a Crux analogue, mostly because my settings and configurations are sometimes intended for still-fresher versions than what Debian testing offers. Part of that would include getting a kernel adjusted to this machine, and considering that Debian has had better luck than I with regard to some things (like the framebuffer), I am willing to take a cue.

A script that scans through the modules you have on board, then tweaks a configuration file for you, would be useful. I think that’s what this does, although as always, I might misunderstand. I promise a report, either way.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

   There will be punch and pie.

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

Now go forth, and be kind to one another.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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