Windows GUI vs. Linux Command Line Myths

Undoubtedly you've heard the old cliché that Windows is easier to maintain because it has GUI tools for everything while Linux requires commands lines and a terminal. Any experienced Windows administrator knows the point-and-click GUI tools don't cover everything. Likewise any experienced Linux administrator knows there are many GUI tools for Linux configuration but terminal shells are available on ANY system regardless of how big or small and the ability to script any action in a platform-neutral way is too useful to give up. I just again encountered a situation on XP that required a command-line fix and it highlights the ignorance of many fanboys about the reality of Windows system administration.

I recently installed Windows XP Pro from scratch on a dual-boot system. I normally install Windows first as it doesn't play well with other OSes when it comes to the boot loader. I was using an original XP OEM CD with SP1 integrated. After installation I copied over SP3 and installed that as well. Doing it this way reduces the number of update/reboot/update cycles I have to go through with Windows Update and reduces the risk of an exploit before the process is complete. After rebooting, I run Windows Update and go through the usual Windows Update update, Installer update, activation, and WGA check. I then install all of the critical updates. There are a surprisingly large number of them considering I already have SP3. Reboot again and run WU again and install NET Framework runtimes, IE7, Media Player 11, and more updates for the updates. Reboot again and go back to WU again. Install more updates for the updates and everything else I just added. Or at least I tried as they refused to install, reporting "failed" for all of them. I went through the typical diagnostics Windows admins have learned over the years of deleting out temp files, clearing the browser settings, and attempting to install each update individually to no avail. Some Google searching turned up a blog posting about Wups2.dll not being registered properly if the system is updated through WU and not rebooted before SP3 is installed (KB943144). Of course this doesn't explain my situation as WU hadn't been used before service pack was installed. The workaround requires stopping the WU service, manually registering the dll from a command window, and restarting the service. This fixed my problem.

This isn't an unusual repair process for a Windows system. Even for Vista there are plenty of examples of command window (cmd.exe) and regedit repair instructions in Microsoft's support pages. You can ignore all the myths floating around the Internet about never having to use Unixy command lines when administering Windows systems because of the wonderful graphical tools. On Windows there are many tasks that are impossible to perform with graphical tools or are just a lot easier from a command window. The only way to avoid command line tools or regedit entirely is to write a custom graphical tool that handles those specific situations (similar to "compiling a kernel" comments from Microsoft fanboys). The fanboys will point out that regedit is a graphical tool but the reality is that it isn't much more of a "tool" than Notepad (which was used in the pre-registry days with win.ini and system.ini). An IT manager that hires an admin that doesn't know how to use regedit or command-line tools should themselves be replaced. When screening job applicants I've encountered many "certified" admins that didn't know anything about maintenance outside of the graphical tools (or even basic hardware troubleshooting for that matter). Surprisingly, I've also worked with software engineers that had a paranoid fear of even regedit. It's like they've been brainwashed into thinking that the only "proper" way to work with the registry is to use an API and approved function calls. Apparently they haven't experienced the "fun" of trying to remove auto-starting malware entries from it.

Because of the emphasis on graphical tools the skill of working at a low level with the Windows OS is a dying art. While the graphical tools lower the barrier for entry into system administration it also invites fools (with only superficial skill) to enter (and get certified) without low-level skills valuable for troubleshooting. Graphical tools provide them a flower-strewn path to anywhere they want to go but when a situation calls for them to go off the path they are lost - much to the pleasure of seasoned consultants who will guide them back to safety for a hefty fee. System administrators are not the types of users that recovery disks were intended for but unfortunately a lot of amateur admins rely on them.

The fundamental limitation of graphical tools is that trying design an interface for every conceivable configuration option, troubleshooting situation, and maintenance function ends up making the tool more complex and time-consuming to use than the task itself. There are occasions when GUIs are easier than command lines but it's usually a situation involving an over-complicated design of the underlying system than a practical improvement in efficiency. The hierarchical structure and relationship of keys and values in the Windows registry is relatively simple but the file format makes regedit a necessity. Typing in a registry key path to a command line application like reg.exe, especially one that includes a GUID, is painful. On Linux you can experience a similar difficulty when trying to work with an XML configuration file like the one pam_mount now uses.

Graphical configuration tools like regedit are not unique to Windows. Gconf-editor provides a similar interface to the Gnome GConf settings database. But the terminal isn't going away anytime soon as it's too powerful and even on Windows the DOS-derived command window is still present. Windows admins have learned to live with its limitations, switched to higher-level programming languages, or extended it with third-party utilities like KiXtart (which I've used). The Windows PowerShell is Microsoft's attempt to replace this last remnant of the DOS era and it's legacy syntax. This may be their admission of the limitations of a GUI or just be a response to the popularity of headless systems in data centers and the need for a replacement to a 20 year old shell. I haven't tried PowerShell myself as I moved away from the Windows platform before it was released. With the availability of virtualization I now just use Windows as a bloated runtime for legacy applications and I don't need to do scripting anymore (although I'll admit to playing with batch files in FreeDOS once in a while).