Title: Editorial

Once again, I've left it too late to write you a studied piece, so I'm going to produce the familiar plea, recount some recent news, and subject you to one of my rants.

This issue the software patterns section swells with some more excellent discussion of common architectural solutions. Look to your project for an elegant reusable concept that you could document for the membership.

At the end of July Linux received a healthy endorsement from a group of software vendors. Informix and Oracle are porting their database servers, and Netscape is porting both Directory and Messaging servers.

Since Linux was introduced, about eight years ago, I've viewed it as a curiosity. I remember installing Minix, the Andrew Tanenbaum tutorial Unix implementation, around that time. I suffered the various trials of downloading disk drivers, patching up the code, compiling it, and re-linking it - all on a single sided 360k floppy. Since those university days, I've been a corporate DOS, Windows, and NT programmer. Not much motivation for battling with homebrew unix.

Anyway, yesterday, I picked up a copy of RedHat 5.1 (a popular Linux distribution) at the local high-tech supermarket - which, incidentally, is now stocking propane fuelled BBQs. I slapped the CD into my homebrew PC. It was installed and running in fifteen minutes. It's amazingly speedy, but the X based administration tools are pitiful, in comparison to NT. Looking forward, some things need to happen before Linux will be a widely acceptable alternative. PC manufacturers will have to start offering it as a pre-installed option on new machines. There need to be big name companies offering technical support contracts. And, the chip manufacturers need to open labs specifically for performance tuning Linux applications. Rumours have it that Intel and Compaq/Digital are looking to fill these roles. Hopefully, this will all come about over the next couple of years.

Anyway, try Linux, you can dual boot it with Win98 ☺

I've seen two projects do this. They put a one month task in the project plan for 'installation'. No one wants much to do with it. It's left unassigned, slowly creeping out to the middle of the schedule. Then someone is lumped with it, and the real requirements start trickling down from management. Suddenly, it's the behemoth of all installation scripts - implemented in that awful windows package that everyone uses. It has Typical install, Custom, install, Upgrade install, Silent install, Migrate 1.x install, Migrate 2.x install, Deploy Standalone, Deploy Cluster, Add-on Package #1, etc, etc.

If you're the unlucky developer creating the software to be is delivered by the 'Mother of all Installers' you're tightly coupled to its progress. You can't install to test when it's broken, or out of date. To try a feature you need to build the code, package the bits, run the installer, curse, fix the installer, package the bits, run the installer, etc, etc.

Advice 1: Make your software self installing. If the expected configuration information doesn't exist, then dump out a default one from static memory. This de-couples the developers, makes the software more resilient to environmental changes, and makes the installation software simpler.

Advice 2: Don't write all those fancy wizards in the installer. Put them in the administration tools so they may be used over and over again. The installation delivers the bits, then launches the regular administration interface.

So, thumping fist on pub table, the installation package should do only what's necessary to bootstrap the software, then you're on to administration.