This issue of Port Of Call has been a particular challenge. In addition to the usual travails of content and layout, fate - with a fair amount of inadvertent help from me - provided substantially more difficulties than normal. Most of the additional complications originated one way or another in the underlying technology used to produce the newsletter.
One of the conundrums of developing computer systems is that once projects reach a point where they're useful, they tend to be used. The more useful they are, the more quickly they become "necessary" parts of everyday life. As they become everyday "necessities", it becomes increasingly difficult to do without them while using their components for further development and testing of the product. The greater their potential contribution to the quality of life of the developer - and ultimately the customers - the greater the difficulty in maintaining a prototype's status as temporary test gear.
The multimedia features in my latest desktop server prototype are a prime example of the usefulness conundrum. As my aging conventional entertainment gear progressively failed, the prototype became my primary means of listening to music, and watching DVDs and television. Even when it wasn't in active use, its video recorder tended to have programs queued up to be recorded.
Since the prototype used its monitor to display full screen enhanced resolution video, it wasn't available for other tasks while functioning as an entertainment system. So I continued to use a previous desktop server prototype for everyday computer functions like email, web browsing, writing, publishing Port of Call, etc. These two machines were the only hardware I had that was powerful enough to be useful for continued multimedia development.
I tend to be an end user of computers. I've accumulated a fair assortment of obsolete equipment that is adequate as test rigs for most of my projects - servers, basic desktop systems, etc., but isn't capable of delivering the level of performance that consumers have come to expect. Unfortunately, my multimedia projects are at the other end of the scale. They've only become possible as hardware has gotten powerful enough to perform the desired tasks. The kind of hardware required for these projects won't become obsolete gear available at little or no cost for several more years when even more powerful hardware displaces it from the commodity hardware market. Until then the type of hardware needed for these projects will continue to be in chronic short supply.
My latest desktop server prototype was finally at the point where I needed to start using it for everyday tasks in order to confirm that it really worked as well in real life as it appeared to in testing, and to find any unexpected bugs before offering it to customers. It was time to merge the functions I was using on two separate computers onto a single machine, and return one of them to the development process.
One of the desktop server's more sophisticated tricks is the ability to support multiple users with "diskless workstations" - in essence additional monitors, keyboards, and mice connected to the server over an ethernet network. All that is needed at the user end of the connection is a minimal "gutted" computer to put pixals on the screen, and relay mouse and keyboard events back to the server. The diskless workstation should have a PCI bus so that cheap mass market ethernet and video cards can be used, and at least 64megs of ram. The clock speed of the processor doesn't make much of a difference, making this a good way to recycle all those "too old and slow for windoze" machines that have been retired before their time by microscam's bloatware.
My usual practice is to assemble whatever test rig I need at the moment out of the assorted parts on hand. One of the machines exempt from this constant reshuffling is my last windoze machine - an old 200Mhz Pentium that I have to keep intact just in case it's needed for tech support.
Since I rarely have any need for a windoze machine these days, the computer has been mostly sitting idle. But not any more. All it took to turn it into a diskless workstation was to launch the Linux boot loader with a floppy disk. (If it had a more sophisticated ethernet card it wouldn't even need the floppy to kick-start the network boot process.) On those increasingly rare occasions when I have a use for a windoze machine, all I have to do is let it boot off its hard drive instead of the floppy.
It might superficially appear that I'm writing this self-promoting essay, and publishing this issue of POC, for the entertainment and edification of the readers. But this issue is being pressed into serving a dual purpose. At present, its primary function is to provide a test load on the new desktop server.
At the moment I'm logged in on the diskless workstation, and I've opened half a dozen Open Office word processor windows - one for each of the various articles and letters being edited for the newsletter. I also have Evolution open so I can periodically check my email, and a terminal window connected to a server across town so I can monitor an ongoing task I'm running remotely. As I type these words in one of the Open Office windows on the diskless workstation, the server is recording a TV show while playing back a previously recorded show on its own monitor. To further load the system, I'm also transferring over 20 gigabytes of Ogg-vorbis music files (roughly 500 CDs) over the network onto the new server's hard drive.
Of course, in keeping with Murphy's law, just when I got deeply involved in moving my day to day operations onto the new desktop server, and assembling the next issue of POC, several unexpected additional crises appeared to further complicate matters.
The first crisis was a call from one of my test sites. It's been well over a year since I replaced the troublesome windoze computers they used for Internet access with diskless workstations running off one of my desktop servers - built out of one of the former windoze computers. Between employees and volunteers, the Linux workstations have become so popular that they're now all in constant use. The organization has just added several temporary employees to help with the run-up to the November election. They needed to immediately expand their Linux system with additional diskless workstations for their new employees.
Following close on the heals of the first crisis, the drive failed on a friend's Linux machine. He thought this would be a good time to update his system to my latest version - as well as set up his wife's windoze machine so that she could use it as a diskless workstation running off his machine, for Internet access. To make things more interesting, my friend wanted his new Linux system to be able to occasionally "dual-boot" to an existing windoze system installed on an old hard drive. And he needed his system back running as quickly as possible since he depends on it for both business and personal use.
During the process of building my new desktop server prototype, I'd updated over 180 packages in the custom Linux distribution I've been developing (including the Open Office version I'm using to publish this issue of POC). The changes I made shouldn't have been a problem - and according to Murphy's law wouldn't have been if there hadn't been a time crunch. But as soon as I was faced with multiple concurrent crises, the previously reliable installer suddenly didn't work anymore. Of course, the CD building process itself didn't crash. It built disks that waited to crash until they were being used to install a new system, thereby wasting the maximum amount of what was already in short supply - time.
Argg...
By the time you read this, I will have dealt with all of the various crises - at least as far as they impact those depending on me. Cleaning up the side effects of the extraordinary measures required to accomplish this primary goal may take a little longer...