At work today, I received an update to an application we run. It's always been a well-behaved, stand-alone application, so I thought nothing of installing it. Indeed, the upgrade went smoothly, with only one weird error message popping up to alert me that the uninstall process wasn't finished. The only option was "OK", so I clicked it and the installed kept on installin'. It rebooted Windows XP when it finished. And then Windows XP rebooted. And rebooted. And rebooted.
Ugh.
This very symptom had actually happened to the same PC at the end of last year. I forget now, what the specific circumstances were then, but I knew right away what search terms to feed to the Microsoft Windows XP Support page:
stop registry hive software
In late December I had a chance to review Article 307545, and it didn't fix the problem I had then. Specifically, I was unable to backup C:/Windows/System32/Config/Software, presumably because it was corrupted. Article 307545 doesn't tell you what to do when the recovery console won't let you copy the registry hive ...
I tried again today to follow the steps outlined in the support note. Again, the reovery console refused to copy the Software hive. I tried skipping that one step, hoping perhaps the remainder of the steps would fix my problem. No such luck. I shoe-horned in the emergency registry hives from C:/Windows/Repair and then moved the hives from the System Restore location. I was feeling confident as I rebooted the machine, expecting to get a login screen. Instead, the system rebooted. And rebooted. And rebooted. All that work to get right back to where I started.
I realized today, in a whole new way, that Microsoft Corporation isn't really concerned with where I want to go today. They're concerned with where their shareholders want to go today. I guess I always kind of knew that, but this was a very personal introduction to that reality.
I've been growing more and more accustomed to GNU/Linux configurations and the above scenario is highly unlikely to occur there. You see, configuration items in GNU/Linux are (almost) always stored as plain text files (usually) in /etc. This means that a user can view and edit their contents with a simple text editor. It also means that the configuration files can be transported between systems in a variety of ways and simply dropped into place. Microsoft's non-text registry is far less flexible, and requires Recovery Consoles and other voodoo to manage.
Applications in GNU/Linux usually stick their global configuration items in /etc, and store per-user configuration items in each user's /home directory. So if the /etc partition blows up, the users ought to retain their specific configuration settings. The Windows registry, as an all-encompassing repository for configuration data, presents a single point of failure for system- and user-level configurations. The data is sprinkled (sometimes redundantly) amongst the various registry hives. A corruption of any part of the registry can often spoil an entire system.
And because Windows so deeply depends on the registry for configuration details, recovery of a dead system can sometimes be a lost cause. At best the steps listed in Article 307545 will work, and you get your computer back; at worst you have to re-install your system from scratch, rebuilding configuration details for each application. Contrast this with GNU/Linux, where a LiveCD like KNOPPIX can provide direct access to all of the plain-text configuration files which can be edited as needed. Or, if a re-install of GNU/Linux is necessary, you can backup your /etc items first, and then simply copy them back to re-configure your system.
Microsoft Windows makes it hard for me to diagnose and maintain a system.
GNU/Linux makes it easy for me to diagnose and maintain my system.
It will be interesting to see what future Windows versions bring. Their .NET Framework, which few Windows applications developers have yet to embrace, but which Web developers have, sidesteps the registry altogether in favor of a "machine within a machine" similar to the JRE. All configuration for .NET applications is held in XML configuration files. .NET components do not have to be registered in the registry, nor do thier configurations. Of course, the .NET framework itself depends upon the Windows OS; it adds a layer, at some performance cost, that allows developers to avoid the traditional "dll hell" problems... None of this really a solution to the problems you expressed, but perhaps it indicates that parties within Microsoft do understand and want to do something about the problem....
However your point is well-taken, that MS' primary interest, like any public company, is to create value for its shareholders, so we can all expect a continual stream of for-pay upgrades and "improvements," many of which will be designed to require additional MS software and MS-certified training. There is no question that Linux is a better mousetrap, particularly from the point of view of IS professionals. What I am interested to see is whether more Linux applications will embrace XML for their configuration files (few do), despite its bloated file sizes (tags to actual config data can be 30:1!). There seems to be growing consensus toward XML, despite the bloat, that I find a little hard to understand...but certainly it's human-readable.