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
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.
-
DebConf24 to be Held in South Korea
Busan will be the location of the latest DebConf running July 28 through August 4
-
Fedora Unleashes Atomic Desktops
Fedora has combined its solid distribution with rpm-ostree system to make it possible to deliver a new family of Fedora spins, called Fedora Atomic Desktops.
-
Bootloader Vulnerability Affects Nearly All Linux Distributions
The developers of shim have released a version to fix numerous security flaws, including one that could enable remote control execution of malicious code under certain circumstances.
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.