The reasons are partly historical: UNIX was originally used in resource-scarce university environments. The ability to do a lot with a little -- power through flexibility and complexity -- was more important than ease-of-use or interface design. Windows is a consumer operating system. It relies heavily on a GUI, the simplicity of which equates to sales. Its vendor jealously guards access to its internals, as is the wont of a corporation that sells software. It even includes a pinball game. It's fair to say that Windows's designers made a different set of assumptions than Unix's. Making the transition from Windows to UNIX system administration, then, can pose considerable philosophical challenges.

Satori
Neal Stephenson, science-fiction author and Linux user, accurately described the process of learning UNIX:

The process of learning it is one of multiple small epiphanies. Typically you are just on the verge of inventing some necessary tool or utility when you realize that someone else has already invented it, and built it in, and this explains some odd file or directory or command that you have noticed but never really understood before.
--From his essay In the Beginning was the Command Line

Satori is a somewhat untranslatable Zen Buddhist term for sudden awareness, apprehension, or understanding -- what Archimedes felt, besides a chill, when he cried "Eureka!" UNIX satori is the sudden absence of challenge, the realization that someone else solved your problem a long time ago. You are NOT unique. If you don't find this in the least disappointing, read on.

The Road to Documentation
We need to know where to begin looking for enlightenment. On Windows, "help" conveniently elicits this:

C:\>help
For more information on a specific command, type HELP command-name.
ASSOC Displays or modifies file extension associations
(about 75 more commands follow…)

The graphical help utility is even more useful, providing a completely indexed set of documentation. Delving a bit further, you might find this easy accessibility illusory, since "Contact Product Support" is the penultimate answer to a number of queries. My Solaris 2.8 system isn't quite so voluble:

$ help
help: not found

Windows documentation assumes that real help is worth paying for, but it rewards your instincts when you go looking. Conversely, UNIX documentation assumes that you already know the answer, and merely need to be reminded of its location in the collective unconscious. Unfortunately, Jung failed to anticipate UNIX. Thus, all introductory UNIX books begin by documenting the documentation. In case you haven't yet got your hands on one of these, let's do that now.

RTFM (If You Can Find It)
UNIX manual pages are arranged in sections, numbered with slight variations between implementations. The following list of Linux manual sections is taken from page 6 of the venerable UNIX System Administration Handbook (more on that later):

1. User-level commands and applications
2. System calls and kernel error codes
3. Library calls
4. Device drivers and network protocols
5. Standard file formats
6. Games and demonstrations
7. Miscellaneous files and documents
8. System administration commands
9. Kernel specifications and interfaces

A special command is used to access the manual pages, "man." So, for instance, this command will display the manual page for the command "ls":

$ man ls
user commands                 ls(1)
NAME
  ls - list contents of directory

It's not always clear in which section the help you need resides, and some commands or files have names that aren't unique in the manual. You can specify a different section explicitly if the help isn't helpful:

$ man –s [section] [command]

For instance, the file /etc/system is important in Solaris, but a plain "man system" query gives us a page unrelated to what we want:

$ man system
standard I/O functions         system(3S)
NAME
    system - issue a shell command

The command "man –s 4 system" gives us something more helpful, out of the File Formats section:

$ man –s 4 system
File Formats                    system(4)
NAME
    system - system configuration information file

Knowing the second cousin of the command you're looking for can also be helpful. If, for instance, I know that I need to obtain information about my system but can't quite remember the command I'm looking for, the manual page for another command that I do know contains a list of related commands:

$ man uname
…
SEE ALSO
    arch(1), isalist(1), sysinfo(2), uname(2), attributes(5), environ (5)

Lastly, there's a limited search function built into the manual page facility. This command will return a list of commands related to the keyword:

$ man -k [keyword]

(By the way, if you're interested in a good list of Command equivalents between UNIX and DOS, click here.)

Self-Help Books
Like Mr. Stephenson, I recommend simple exploration of the system as the best way to learn UNIX. Randomly browsing the UNIX manual pages presupposes a certain amount of knowledge, though, and will only get you so far. Additionally, the Web has decreased the utility of UNIX manual pages, simply because vendors update their HTML-based documentation instead, anticipating that you'll obtain what you need from their Web site. To compensate for this lack, there are several "bibles" for UNIX administrators that provide excellent general overviews. Reading one or more should ensure that you know how to ask the right questions. This is the only time I'll ever recommend a self-help book of any persuasion, by the way.

O'Reilly and Associates publish the best introductory UNIX text: Essential System Administration by Aeleen Frisch, also known as "the blue book with the armadillo on the cover." Like most O'Reilly texts, it jumps straight into the details of what you need to know to get to work: Adding and deleting users, configuring networking and so on. It can be Spartan on the details of why things are done a certain way, though.

The UNIX System Administration Handbook provides the real details of why UNIX works the way it does. It delves right into the process of how a UNIX system starts up and shuts down, on a script-by-script level -- something that you might not have to know for years, given Unix's stability. It then moves on to less obscure topics, like increasing the priority of a process and the difference between character and block device files. In short, it's not for the timid. The second edition "red book" changed to purple in the third edition. It also covers fewer versions of UNIX, to reflect a changing market -- Solaris, Linux, HP-UX and FreeBSD. If you have some other flavor of UNIX or are a Sinologist, seek out the older edition.

Bad Habits
The expatriate NT administrator's most difficult task is overcoming certain habits that aren't detrimental in the more sheltered Windows environment. Here's some common concepts for UNIX systems that every NT admin should learn:

Rebooting Solves Nothing
While rebooting is still a sort of all-purpose hammer for Windows, it's the single most dangerous thing you can do to a UNIX system, acts of passion excepted. Rebooting can make it impossible to replicate a problem or recover debugging information -- especially if a hacker has configured the system to self-immolate upon reboot. Large UNIX systems also perform numerous self-checks upon reboot, and can take hours to resurrect themselves if they are brought down suddenly -- hours during which users become increasingly frustrated. A reboot should always be planned in advance and the integrity of backups checked prior to the act. Unplanned reboots are normally only necessary to clean out "zombie" processes that can't be killed any other way, or to recover from the rare complete system hang.

The Shortest Distance Between Any Two Points Is a Command Line
As alluded earlier, the UNIX graphical user interface, X-Windows, is an afterthought. UNIX betrays its command-line origins at every turn, and it's to your distinct advantage to regard all other interfaces with fear and loathing. A quick story from the trenches: The other day a colleague of mine attempted to remove a LUN (logical unit number) from his fiber-channel disk array for several hours using the graphical tool, only to call support and have them direct him to use the command-line tool, which worked instantly. Anecdotal evidence is no evidence at all, but my command-line preference has some scientific basis. The greater the number of components involved in any operation, the greater the number of connections between those components, the greater the number of things that can go wrong. Applying Occam's razor, the simplest solution is generally correct, and the simplest path to any UNIX destination is via the command line.

Only You Can Protect Yourself
To illustrate this, let's compare what you have to do to delete a file on the two platforms:

Windows:

1. Right-click on the file.
2. Select "Delete."
3. Click "Yes" when asked if you're sure you want to delete the file. At this point, the file is relocated to the "Recycle Bin."
4. Right-click on the Recycle Bin.
5. Select "Empty Recycle Bin."
6. Click "Yes" when asked if you're sure you really want to delete the file. At this point, the file is deleted.

UNIX:

1. Type "rm [filename]"
2. Hit Enter

At this point, the file is deleted. Also at this point, you realize that instead of typing "temp*" you typed "temp *" with a space between the "temp" and the asterisk, thereby removing every file in your home directory. No one hears your screams.

UNIX provides few buffers between you and disaster, whereas Windows, whatever its faults, does try to thwart your more self-destructive behavior. Never assume that a UNIX system will tell you something's not a good idea.

Be Careful What You Wish For ...
As elsewhere, UNIX's Golden Rule is: Do unto it, as you would have it do unto you, else woe betide you. Neal Stephenson aptly compared UNIX to the title talisman in W.W. Jacobs' famous short story, "The Monkey's Paw" (updated in Stephen King's Pet Sematary, for our modern readers). Even seemingly innocuous wishes can instigate disaster.

In the next installment, we'll be covering the UNIX security model, user environment, and other things you might be motivated to do unto your system. In the meantime, you might want to peruse the following UNIX sites: Introduction to UNIX, The UNIX Reference Desk and UNIX Guru Universe.

Are you an NT administrator moving into Linux/UNIX? What's your experience been like so far? Post your comments below.