Linux, OpenBSD, Windows Server Comparison: Ease of Learning vs. Use & Repetitive Tasks

• Windows Lacks Automation
• Smart Monkey Administrators

Since the widespread adoption of graphical user interfaces the entire computer industry and especially the trade press have almost universally confused two very different concepts. These are "Ease of Use" and "Ease of Learning". Ease of use is widely discussed and often regarded as one of the more important characteristics of any software product. The phrase ease of learning is not often used. In nearly every instance where the phrase ease of use appears in computer related literature, the phrase ease of learning should instead be substituted. Ease of use is nearly always used to mean that a product is easy to learn to use.

Products are easy to learn to use for any of several reasons. First, most (graphical) products today follow highly standardized user interface conventions so that once a users becomes familiar with the behavior of a particular widget, they have a good idea how a similar widget in another location or product will behave. Certain widgets tend to be located in very standardized locations. The actual name and icons associated with widgets varies but to the extent that names and icons carry across products and even platforms, this also aids user learning. Specific products will be easy to learn to use if the product developers anticipate user behavior and group product specific functions naturally under headings where users first look for them. If developers fail to anticipate user behavior and place functions where users have to search multiple menu entries to find them, the product will be regarded as hard to use.

Thus ease of use normally means how easily a user new to a product can figure out how to perform a specific action. Rarely is the ease that the tenth or one hundredth time the same action performed a topic for discussion. By the very nature of product reviews, operations are not repetitive. About the closest anyone comes to covering these issues is the occasional mention that a very common actions has no hot key and requires three or more menu selections to accomplish. In end user applications, many of the operations that once required macros to do efficiently, now have built in functions that perform the operation more naturally such as style sheets and templates, predefined envelope printing functions, built in database capabilities for merges, etc. Generally, end user office productivity applications do not have a lot of multi step functions, that need to be performed frequently.

In the area of system administration however, there are a number of tasks that are likely to be highly repetitive. The GUI tools that make office applications easy to learn, may also make system administration tasks also easy to learn. When we say easy to learn, we're talking simply about the mechanical steps to perform some task; it's unlikely that performing such a task, using a GUI or menu interface, will aid the administrator in understanding the concepts behind what is being done. The multi layered menus and graphical selection tools that may make finding and changing some setting simpler when well planned, may also make these tasks very burdensome to perform repeatedly, such as on a weekly, daily or even more frequent basis. To compensate, some of the most rigidly repetitive tasks, such as backups, include their own schedulers or can make use of a standard system scheduler.

In addition to the technical characteristics of the user interface, other factors are also related to both ease of learning and ease of use. These include the quality and availability of documentation, system architecture and whether it is designed to be open to users or hidden, and the availability of support and training services. These will also be discussed.

Windows Lacks Automation

Some processes can become quite tedious and labor intensive. Adding new users is a prime example. Compared to the tricky UNIX command line syntax of useradd and related utilities, opening a Windows User Manger window, clicking on new users, filling in several fields and opening the group dialog and control clicking several groups and then the add button or double clicking each group successively seems simple. For one or a few users, it is. As the number of users to be added or updated increases, the mechanics of opening and closing a several windows or dialogs per user can become quite tedious. I can't imagine using User Manager in academic environment, where there might be thousands of users to add and remove, each quarter or semester.

Though the basic UNIX user maintenance commands may be more complex initially than User Manager, they can be used in scripts. Even a modest size business, say 50 or more employees, has enough turnover, that in the long run a script is likely to be well worth while. For example, a number of access permissions and defaults are likely to be determined by a user's department. These might include access to several applications, a default printer, whether access to the command prompt is allowed, whether remote access is allowed, and membership in at least one and quite possibly multiple user groups. With a script, adding a new user should only require typing the script name, the username, the user's full name and the user's department abbreviation at the command prompt. The initial password is entered interactively, when prompted. In many environments, with a well planned script, this would be all that would be needed for most users. The unusual users would be handled on a case by case basis with the command line, text or GUI system administration tools appropriate to the system. For an academic environment, a script would process a list, hopefully created from enrollment or registration applications, and automatically create users as needed.

The point of this is that, the easy to learn Windows tools, become cumbersome to use as the tasks become more repetitive. At large enough volumes, the Windows tools simply become unusable. There are add on solutions on Windows systems, but when it's necessary to turn to them, it's not reasonable to claim "ease of use" as a Windows advantage. A modest priced add-on, the Resource Kit, may provide a sufficient solution in conjunction with scripting skills. Alternatively, an expensive commercial add-on may be the answer, though the open source and free, UNIX derived, Perl scripting language (included with nearly every UNIX like system and available for free on every significant platform today), is a powerful administrator supplement on Windows, and could handle the kinds of tasks described here.

Perl script skills are common on UNIX and rare on Windows; there are no scripting skills that are routine part of Windows administration. Even batch programming skills, as simple (and limited) as that "language" is, have largely fallen into disuse. Most Windows administrators are entirely dependent on the GUI management interface, and even where it should be obvious that something should be automated, do not have the knowledge or skills to do it. Only where automation is an inherent part of the management tool being used, such as backup programs, are Windows management tasks normally automated. UNIX administrators, in contrast, are normally skilled in at least one scripting language, and routinely expect to automate repetitive parts of their jobs.

The typical product review, including operating system reviews, necessarily focus on setup and ease of learning issues, feature list comparisons and possibly performance as well as other factors that can be compared in relatively brief periods during which the products are being compared. No standard product review can easily focus on long term maintenance issues in a test environment. Only someone with significant experience in the day to day administration of both types of systems, is in a good position to make meaningful comparisons on these issues.

I've said enough to suggest that Windows server systems have a pro novice bias and that UNIX systems have an anti-novice bias because of the admitted up-front learning curve. Elsewhere, I've said with expert level administrators, Windows servers can be made adequately reliable and secure even though as a practical matter, Window's servers typically lag significantly behind UNIX servers in these areas. What about the majority of system administrators who are somewhere in the middle, neither novice nor expert?

After a fairly brief introductory period, Windows exhausts its novice bias, and fairly quickly becomes a hindrance to the continued learning by those administering it. Over time, experience will broaden as any administrator learns more products and becomes increasingly familiar with the menu structure of products they already use. A corresponding learning is likely to develop on any system. On UNIX, an administrator learns a growing variety of utilities, additional command options for utilities they are somewhat familiar with, and perhaps more important, a growing mastery of scripting syntax and both data and logic structures.

On Windows however, at the point that an administrator learns the menus, they hit a barrier beyond which Windows neither encourages growth, nor provides any tools with which to grow. Absent formal training and development programs, any Windows administrator is likely to reach a technical plateau beyond which they will not progress. Once they've learned the mechanics, what opportunities does Windows present for further development? When a job becomes repetitive how can it be automated? On UNIX, there is always more to learn. Any administrator can go as deep into the system, as the demands of their job and their own desires and skills allow, even to learning how a system works at the source code level, at least on the open source, UNIX like systems.

Some might argue that it's not reasonable for me to try to apply my 18 years of experience, including much software development, to "typical" administrators with one to five years of experience. I disagree. For reasons of necessity or choice, my career has moved over a variety of platforms creating a very broad knowledge, but I've never spent enough time on any system to reach what I consider an expert level. I don't mean to dismiss experience. My experience should give me both a conceptual framework and a variety of mechanics against which to compare any new system; I should be able to learn a new system faster than someone with less experience or skill. That doesn't mean that I should not be able to recognize obstacles to learning present on one system and not another.

With all my experience, if I hit obstacles on Windows, that I can't find my way around, the less experienced are even more likely to. Two common ways of dealing with Windows problems, rebooting and reinstalling illustrate exactly what I'm talking about. Neither is problem solving. Both are problem erasing. In one case you erase what's in memory, and the other what's on disk, to get back to a simpler state, in which the problem hopefully won't appear. It's pure luck whether the "fix" is temporary or permanent, because in neither case are the specific origins of the problem determined and eliminated. Even if all user data is saved, except on the newest systems, which don't normally have unexplained problems, a significant amount of both administrator and user time is lost, as the user will attempt to restore the system to whatever state they may have previously customized it. In my experience, these kinds of problems don't occur on UNIX.

If on a UNIX system, I carry automation further in either extent ("all routine tasks") or depth ("home grown intrusion detection") than a less experienced administrator, it doesn't mean the less experienced administrator won't be able to take advantage of the same tools and basic approaches on UNIX that I use. What seems routine will vary greatly with level of experience, as experience helps to see patterns that may otherwise not be apparent. Regardless of an administrator's level of experience, some tasks will become boring; boring is almost by definition, routine.

The first tasks a less experienced administrator automates, will be the simplest, most mechanical, and obviously repetitive tasks, and the scripts will be simple and deal with few if any exceptions. These come with experience. Also with experience, more things seem routine, and scripting skills evolve with level of experience. As soon as an administrator overcomes the unfamiliarity and apparent difficulty of a UNIX command line interface, which should not be more than several months in most cases, an administrator is limited only by their own abilities and not any artificially imposed system limits. The longer an individual has spent in a Windows or other environment with no meaningful command line experience of any kind, the more difficult the transition is likely to be, and some may not be able to make the transition.

System backup is perhaps, the most basic administrative task. If a Windows NT Server is on a budget and no third party backup products have been purchased the options are fairly limited. We'll assume that a tape drive was purchased which allows NTbackup to be used. This is an interactive GUI program but unlike most others, does include a useful set of command line arguments. What are the options available to an administrator? One is to not do backups which should not be acceptable. Next is to run NTbackup interactively. It's a simple program so it should be possible to do other things while it runs. In practice, it pops up a fair number of dialog boxes while it runs. You can do other things but not without interruptions and thus not very efficiently. If backups are performed interactively, they will be missed when the administrator is under time pressures and other tasks will be performed inefficiently while backups are run.

The last option is to automate backups to run during the night which is also likely to reduce the number of shared file conflicts. This requires learning NTbackup's command options and getting them into the system schedule via at.exe. This is very limited compared to cron but adequate for daily backups. The command, at.exe, is one of the few Windows commands of any importance, that has a command line form, without a GUI counterpart. (If you have the Resource Kit, "Winat" is a GUI substitute but is somewhat more limited than the command line version.) This in itself, says a lot about how unimportant repetitive tasks were to Microsoft, when it designed Windows NT. Of course if enough customers ask for functionality, Microsoft will include it. As they try to get their systems to compete with higher end systems, naturally Windows will acquire more of what is taken for granted in the UNIX world. When you see important multi user capabilities missing from Windows systems, remembering that Microsoft and its Windows operating systems are still growing up from single user systems will help understand the situation.

Returning to backup, if you want to do anything more than the most basic backup, such as change log file names on a rotating basis, then some scripting skills are required. Batch programming is not good at this kind of substitution and Perl or any serious scripting language, without previous experience, is likely to be too much of a hurdle to be practical. So even though Windows NT appears to have the tools to automate backups, there is a good chance there will be obstacles preventing a Windows only administrator from actually automating it, without third party tools such as backup programs that include their own scheduling options. Most other system administration tasks on Windows systems present even less opportunity for automation, without the use of third party tools.

On Windows systems, once the mechanics of the day to day job are mastered, Windows administration is likely to be boring on one hand because of the necessary repetition and frustrating on the other because of problems that are "fixed" but not solved.

Smart Monkey Administrators

Trying to hide the fundamental workings of the computer for a computer system administrator is like trying to train phone and photocopy repair persons or auto mechanics without training them in how the devices they repair, function in the first place. Without conceptual understanding, the best that can be accomplished is to follow predefined checklists and match observed results to predetermined decision trees. While this is a valuable diagnostic technique, it only covers standard, well understood problems, i.e., those that have already occurred with such frequency, that their determination and correction has been documented. It reduces the administrator to the proverbial "smart monkey". After the predefined troubleshooting steps have been performed, they can only guess at solutions or call for help.

Understanding the system with a problem allows two things that lack of understanding does not. First, the person who understands the system with a problem may, almost immediately see the problem and solution, without methodically following an involved, step by step diagnostic procedure. Second and more importantly, someone who understands a system, has a good chance of finding and fixing the problem or at least finding a satisfactory work around, for new or infrequent problems, that are not already clearly documented.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.