Lew's blog

I thought that I might have a slow winter this year. Boy was I wrong.

I've got more work than I expected, and certainly enough to keep me busy for the next several months. In fact, I'm so wrapped up with Linux-related stuff, that I can't wait for spring to arrive, just so I can get out and away from the computer.

Recently, I upgraded my server from Slackware 13.0 to Slackware 14.0, and ran into compatibility issues with a few of the web applications served from that system. PhpRecipeBook, a recipe manager application running under the Apache web server and PHP, failed spectacularly.

My very backlevel installation of PhpRecipeBook was not compatible with the new level of PHP, and I lost access to the handful of (to me, important) recipes that I had collected over the years. The developers of PhpRecipeBook provide no upgrade path from the level I run at to any supported level of the application. To install the current level (or any level that there is a migration path to the current level from), I have to wipe out my existing recipe collection and start from scratch.

But, before I do that, I need to recover the existing recipes, in order to input them (again) into the new, upgraded recipe book.

An article caught by an "aggregator" site caught my eye the other day: The "EFY Times" published an article of reader-submitted "tips" entitled "20 Linux Tips Worth Trying". Now, being someone who is interested in all the "tips" I can get, I read the article. And regretted it.

It appears that the "EFY Times" was lazy. They didn't vet the "tips" at all. Instead of a list of dependable, well-understood tips, the article contained a lot of poorly selected, side-effect-ridden, and just plain sloppy suggestions from (apparently) self-taught linux users.

I run Slackware on two of my systems. I have always admired Slackware's simplicity and honesty. Some people accuse it of being overly complex, but I've found that what others see as complexity, I see as the ability to control and fine-tune. Other distributions may be great for those who are looking for a Unix system with a Microsoft feel, but I prefer my OS to not hide it's controls, to not tell me that, for my own good, it won't do what I want it to do.

Slackware's run-parts(8) is one of those simple tools that works well. Built from a simple /bin/sh script, and using basic Linux tools, Slackware's run-parts does the basic work of "batch" processing for cron. But, this simplicity has it's price; target scripts are run synchronously, one after the other. If one get's stuck, the remainder can't run. And, there's no easy way to determine if a script has got "stuck"; there's no conveniently accessable logging of the start or termination of each script, nor is there any consistent way to gather messages from the scripts into one place.

And, so, my pet peeve: run-parts(8) doesn't do everything that I need in a batch processor. So, I went and built my own add-on solution.

Recently, something went drastically wrong with my KDE 3.5 desktop (yes, I still use KDE 3.5). Long story short, KDE 3.5 now has problems creating content in .directory files. It will sometimes create the file, but leave it empty (0 bytes written). If such an empty .directory file is encountered by Konqueror, or any of the KDE directory selection tools (for example, a file open dialog), it immediately hangs the application.

A couple of weeks ago, I bought myself a Pogoplug (V2, gray) to try out. The PogoPlug comes with an embedded linux system, and is set up to externalize (through my.pogoplug.com) any USB storage device you connect to it. I wasn't as much interested in the services of my.pogoplug.com as I was in using the device as a general-purpose linux system.