The Needs of the Many
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
comments powered by DisqusSubscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
New Steam Client Ups the Ante for Linux
The latest release from Steam has some pretty cool tricks up its sleeve.
-
Gnome OS Transitioning Toward a General-Purpose Distro
If you're looking for the perfectly vanilla take on the Gnome desktop, Gnome OS might be for you.
-
Fedora 41 Released with New Features
If you're a Fedora fan or just looking for a Linux distribution to help you migrate from Windows, Fedora 41 might be just the ticket.
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.
-
System76 Unveils an Ampere-Powered Thelio Desktop
If you're looking for a new desktop system for developing autonomous driving and software-defined vehicle solutions. System76 has you covered.
-
VirtualBox 7.1.4 Includes Initial Support for Linux kernel 6.12
The latest version of VirtualBox has arrived and it not only adds initial support for kernel 6.12 but another feature that will make using the virtual machine tool much easier.
-
New Slimbook EVO with Raw AMD Ryzen Power
If you're looking for serious power in a 14" ultrabook that is powered by Linux, Slimbook has just the thing for you.
-
The Gnome Foundation Struggling to Stay Afloat
The foundation behind the Gnome desktop environment is having to go through some serious belt-tightening due to continued financial problems.
-
Thousands of Linux Servers Infected with Stealth Malware Since 2021
Perfctl is capable of remaining undetected, which makes it dangerous and hard to mitigate.
I coudn't agree more
Well said!
Never had to re-install
Nice article
I, definitely, think so.
There are Linux distributions that do this
I have never reinstalled a Linux machine that I had also installed. Not even the ones where there was a hardware failure. The closest I got to reinstalled was restoring from backups to a new hard disk.
My record was a machine in the 90's that started with parts ABCD and after some years had WXYZ, meaning, everything had been replaced, including the hard drives. Parts were switched, machine was brought back online and everything kept running as usual.