Paw Prints: Writings of the maddog

"The Needs of the Many Must Outweigh the Needs of the Few..or the One." - Spock in “Star Trek: The Wrath of Khan”

With those words Spock chose to die in order to save the rest of the crew. Philosophically whether you agree to what Spock said or not, an important part of the lesson was that Spock chose to act the way he did...he exercised choice.

Sometimes developers inadvertantly do not offer as much choice to their customers as they should. For example, when we choose not to engineer and offer a clean upgrade path to a new version of a program or distribution.

Many years ago I helped design a new "update" facility for Digital's Ultrix operating system. This procedure allowed customers to simply install the system without having to:

o boot the system from tape to single user mode

o edit the configuration file for the kernel

o type in all sorts of arcane technical data about disk controllers,, serial line controllers, etc.

o rebuild the kernel

o install the kernel in place

o reboot the system

Instead, my procedure allowed the booted kernel to probe the system's bus using a DEC standard that hardware field service people followed as they installed new systems. I had actually been told by one kernel engineer that this was "impossible for Unix to do". I prototyped a solution in less than a day.

After that I was told that by a fairly savvy field service engineer that this procedure would fail because all those "crazy Unix people" ignored the DEC standard techniques of hardware placement in the bus and put the hardware controllers “everywhere and anywhere” in the bus address space, therefore negating the Digital standard.

I argued that most of the time it was DEC field service people that installed the systems and those field service engineers put the components in the right place, and why should we punish all of the people that put things in the right place just to alleviate the pain of some people that did not? I also pointed out that a lot of the existing systems sometime dual-booted VMS (this was before the days of “OpenVMS”), or were former VMS systems that were now running Unix and therefore probably had the hardware components in the “right place”.

To make this field service person feel better, we changed my prototype to probe the bus, show the person installing the software what controllers were found by the process, then gave the installer an opportunity to change the configuration file to what they needed before continuing.

We received rave reviews for the new functionality. 99.99% (perhaps even higher) of the customers had standard hardware in standard places, or non-DEC hardware that followed the same standards as DEC hardware, and the customers loved the fact the system installed so easily.

Today some distributions do not work very hard at doing “updates” from one release to another. There seems to be little thought or work done to allow the customer to update their systems in place, mostly because of the perception that most customers change and tailor their Linux system, and the fear that the update would overwrite the customer's changes.

To be fair, in the past the amount of tailoring that customers do of a distribution would tend to defeat the concept of a “default” installation. Linux (and Unix) people do tend to “change their environment” by creating different file systems, different size file systems, applying different applications and storing them in different places in the file system hierarchy.

However I feel that many of today's customers use the distribution more or less “as is”, with less tailoring than before, so the goal should be (in my humble opinion), to allow for customers to continuously update.

It occurs to me that by not planning for "updates" a distribution may be punishing customers that do not change the stock system in order to protect those that do. We should be designing and orchestrating Linux distributions for the 75 or 80% of people who use a "stock" system, but still allow people the choice of changing the system if they desire to do that. If we engineer a distribution for update, then perhaps even major changes can be “updated” rather than “re-installed”.

Those people that choose to modify their systems outside the bounds of the engineered update may still have to “re-install”, but I think it is better that only 20-25% of the customers have to re-install than 100%

Of course even with an engineered process people should still do backups before updating, and perhaps a test of the update, but if they have thousands of systems to update and they have followed the guidelines put out by the distribution, it should be easier to update those thousands of systems than to re-install them.

Don't punish the many because of the few. Engineer and develop for updates.

Carpe Diem!

Comments