eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Traveling through Russia last month, a BBC reporter was challenged by police after being observed taking pictures of a river. Asking why he should have sought permission to film at that location, he was told, “There was a bridge nearby.” He asked how he could have known. A bridge guard replied, “There used to be a sign there; it just fell off a week ago.” Asking why no one had put up a new sign, he was told, “Thats not my job.”
Some of the people who maintain software updates must get the same training as those Russian guards. Its not their job to tell you what you need to know; its your job to ask before knowing that the question might arise.
For example, after installing Version 10.3 of Mac OS X, I found that I could no longer use Symantecs Norton Personal Firewall—despite having maintained that product with regular LiveUpdate sessions. A Google search took me to a Symantec Web page that began, “Symantec Macintosh software is not yet fully compatible with Apples new operating system Mac OS X 10.3 …”
All right, I thought, best to uninstall it, and I ran the uninstall script from the Norton Internet Security CD—only to be told that uninstallation had failed. Back to that Web page. Sure enough, the very last paragraph helpfully warns, “If you want to uninstall a Symantec Macintosh product from Mac OS 10.3, download the Symantec Uninstaller. …” Oh.
I managed to clean up the mess, but the episode raised several questions. Why wasnt the original uninstaller designed to detect that it was playing on the wrong field? Alternatively, why wasnt an updated uninstaller already on my machine as a result of previous software updates?
My more general point is this: None of us is doing anything on our PCs for the first time, or the last. The products that we buy and the systems that support them need to be designed to work in environments that are subject to change.
My concerns are amplified when Im about to trust a piece of software with the integrity of my entire file system. For example, the most recent version of Symantecs Norton Disk Doctor told me that I had major errors on my OS X disk—but it also thought that I was still running a variant of OS X Version 10.2. At that point, I was about as likely to let Norton Speed Disk optimize my files as I would be to get elective surgery from a doctor who called me “Maam.”
An earlier software update incident illustrates another aspect of software design for a changing world. A few years ago, a Network Associates update for McAfee VirusScan damaged master boot records on Windows NT 4.0, resulting in the startup message “Operating system not found.” Oops.
Network Associates protested that the conflict involved a version of its product that was, at the time, almost 2 years old, to which I reply that two years is not a long time. When I take a new job, I plan to keep it at least that long. Two-year-old software should not be considered abandonware.
Were moving into environments where code is constantly subject to external changes, whether by update services or because the code itself resides remotely under some other partys control. In these situations, I need to know that software authors have anticipated the possibility that things might change. I want to know that theyve told their code to verify its assumptions before proceeding with potentially dangerous actions.
When software has regular opportunities to phone home for updates, as is the case for almost all software installations today, the mother ship must go beyond merely answering the questions that I happen to ask. I should get warnings when ordinary actions, especially damage-limiting actions such as uninstalling an application, enter unknown territory in which my systems integrity may be at risk.
When the issue is preservation of data, I want to be confident that software knows exactly what its doing or at least that software writers have designed their works to know their limits—and to do, as an absolute minimum, no harm.
Discuss this in the eWEEK forum.
Technology Editor Peter Coffees e-mail address is [email protected].