An Introduction to Unix

1.3. Reflections on MS Windows & Unix

Of course, both MS Windows and Unix continued to evolve past their earliest forms, but the contexts in which they have evolved helped establish their fundamental philosophy and continues to influence how they work today.

Unix users tend to do a lot more typing than Windows users. Graphics capabilities were rare when Unix was developed, so commands had to be typed out rather than always working through a window GUI, and that practice of typing commands continues to influence the “look and feel” of Unix. Unix does have a windowing GUI, but the Unix approach is to launch an application via a typed command, then let that application open up windows if it needs them. Compare to MS Windows, where most users never type a command, and may not even realize that many common Windows applications offer a variety of command line options. (Try, for example, creating shortcuts on your Windows desktop with the Target:
C:\WINDOWS\EXPLORER.EXE
and another with the Target:
C:\WINDOWS\EXPLORER.EXE /n,/e,c:\
Try them each and see what they do. The difference is potentially useful, but this possibility is unknown to most Windows users.
Because graphics capabilities were rare when Unix was developed, many Unix applications are text based. The canonical Unix application reads a stream of text in (from “standard input” ) and produces a stream of text as output (on “standard output” ). Because the output is often considered a slightly modified version of the input, such programs are called filters. Unix users are more likely to string together a bunch of filters that each do something simple than to hunt for a massive dedicated application that does the whole job at once. For example, if you wanted to know how many statements occurred in some file of C++ code, an MS Windows programmer would load that file into a visual C++ programming environment, then search through the menu bars for a “properties” or “number of statements” item that might convey the required information. A Unix programmer would, in a single line of text commands, feed that file into a program that extracted each line containing a “;” (because most C++ statements end with semicolons) and then feed that set of “;” -containing lines through a line-counting filter.
“One user -- One CPU” thinking dominates Windows applications even though networking is widely available. MS Windows has never offered the same level of protection against one process affecting others on the same machine. In Windows, it's still all too common for a single crashing application to lock up the machine to the point where a reboot is required. In Unix, such reboots are quite rare.
In part, this is because Unix allows processes to interact in only two ways:
- By having one process write out files that the other reads
- By having one process write characters into a “pipeline” that is read by another process.
By contrast, MS Windows has a variety of communication mechanisms, some of which allow one process to directly manipulate the data of another. This allows different applications to work together in interesting and valuable ways (e.g., embedding charts from a spreadsheet directly inside a word-processor document), but at an inevitable cost to overall system security and stability.
Unix applications are often designed to be run remotely, via a network. Even the Unix windowing GUI, called X, is based on the idea that an application can be run on whatever machine it is installed upon, but will actually display its windows on and accept its mouse clicks and other inputs from any machine on the network. MS Windows, on the other hand, assumes that the application is running on the machine where its outputs should be displayed. If you want to use, say, a paint program that isn't installed on the PC you are sitting at but is installed on another PC in the same room, you can't run that program without actually getting up and moving to the other PC.
Another instance of this bias, one that is, I suspect, much closer to the hearts and pocketbooks of Windows applications developers, can be seen in the deliberate ignorance of many applications to the realities of the networking world. Although Windows will provide support for different users logging in (one at a time!) to given PC, the majority of application software that a user might install on that PC will assume that a single data area and a single set of option and preference settings are enough for that PC. Therefore every time you change a setting, you affect the behavior of that application not only for yourself, but for all other people who use that same machine. Unix applications, on the other hand, are far more likely to be distributed under site licenses permitting all users at a site equal access.3
Indeed, Unix applications are far more likely to be distributed with source code. It's worth noting that both the Free Software movement and the Open Source movement originated in the Unix community. By contrast, Microsoft has recently contended that any software that is distributed free of charge or that is distributed with source code is “potentially viral” and “anti-American” .

If you have PCs arranged on a network, so that they can access a common pool of disk drives, when you purchase a new windows application, it is likely to try to install itself onto a single PC, not allowing itself to be run from the other PCs that can access the drive where you install the software. And even if you could run it by from a different PC, you will often find that all of your preferences or options settings and all of your accumulated data is squirreled away in the registry or systems area of the PC on which the software was installed, making it unusable from other PCs.

All this may help to explain why the CS Dept. makes such heavy use of Unix. It's not that we dislike MS WIndows. But if we require a particular software package (say, a compiler) in our classes, under Unix we install it on a few Unix machines and let students run it from remote locations via the internet. Under Windows we have to install it on every CS Dept machine, ask that it be installed on every machine in the ODU laboratories (and at the distance learning sites). And when an updated version of that package comes out, we have to go through the entire process all over again. It's just far, far easier to maintain a consistent working envoronment for all students under Unix.

3. Indeed, Unix applications are far more likely to be distributed with source code. It's worth noting that both the Free Software movement and the Open Source movement originated in the Unix community. By contrast, Microsoft has recently contended that any software that is distributed free of charge or that is distributed with source code is “potentially viral” and “anti-American” . (back)

There are two ways to interact with Unix and Unix programs: through a text-only interface, or via a windows interface --- the Unix windowing system is called X. Which mode of interaction you use depends upon how you are accessing to the network, the software on the machine you are sitting at, and how fast your connection to the network is. But even if you are running X, one of the first things you are likely to open is an “xterm” , a text-only command window. Unix users tend to launch programs from the text-only interface. If the program itself supports windows, mice, etc., then they can point and click to their heart's content.

In this section, we'll concentrate on access via ssh, an internet protocol for issuing interactive commands to remote machines. Window-based X access will be introduced later.

There is an older text-based protocol for giving commands to Unix called "telnet". telnet is still used for a variety of purposes, but has fallen out of favor because it sends everything (including your login name and password) in plain-text format, leaving you vulnerable to someone else on your network eavesdropping via "packet sniffers".

By contrast, ssh encrypts all your communications, so you are safe even if someone is eavedropping. As of Summer 2008, the ODU CS dept will no longer support telnet connections.