Text-only text editors for Linux are plentiful and include such stripped-down tools as vi, jed, and nano, as well as much more powerful programs such as Emacs.

Word processing as we know it today is usually implemented in GUI programs, but you can create, edit, and print documents using a text editor and a text-mode document processing system such as LaTeX. Indeed, some people prefer using such tools to using the more popular word processors. Even for word-processor fans, a few are available in text mode, although they tend to be old. The commercial WordPerfect for Linux, although best-known as a GUI program, had a text-mode variant, for instance.

In addition to word processing, other traditional office tools are available in text-only versions. For instance, the SC and SS spreadsheets run entirely in text mode. Even some graphics programs run in text mode, but typically just to convert between file formats and the like.

Most Linux compilers are, first and foremost, text-mode tools. Although GUI frontends are available, the GNU Compiler Collection (GCC) and many other development tools run just fine from text-mode logins.

Most network protocols have text-mode clients available. A Linux system can function as a limited door onto the Internet for a network that’s otherwise restricted in access; users can log into a Linux system and run mail clients such as Pine and Mutt, FTP clients such as ftp, and even web browsers such as lynx.

You can run a server computer without a monitor, and sometimes even without a keyboard, as a way to save space and money. Such systems must be administered remotely, although you may have a choice of text-based, GUI, web-based, or perhaps other methods of remote administration.

Sometimes it’s helpful to have access to two systems’ configurations on one screen. You can open a pair of xterm windows in a GUI window, use a text-mode access protocol to log into one system from another, and compare the systems’ configurations in the two windows. This can be a handy approach even if the two computers are just a few feet apart.

If your site uses Linux desktop systems, remote administration of those systems can be a real time-saver. Rather than run around your site to investigate problems, you can log into computers remotely and run text-based diagnostic commands. The same approach is helpful if you’ve got multiple server computers in different locations.

Sometimes a computer must be located in a physically inaccessible location. A common example is a colocated web server, which is housed at an Internet Service Provider’s (ISP) office to gain access to that ISP’s high-speed Internet connection. Systems housed at branch offices, used for automated remote data collection, and so on also qualify in this category.

If you’re at home or on vacation when a dire problem occurs on a Linux system at work, you may be able to use a remote text-mode protocol to quickly fix the problem. Of course, chances are you won’t like getting the call during your off hours, but being able to fix the problem remotely beats having to go in to work on your day off!

Just as ordinary users can telecommute with the help of remote access tools, you may be able to do the same with your system administration duties.

This is one of the oldest protocols in common use, and also one of the simplest. It basically sets up a two-way text link, in which the characters you type are passed over the network to the remote system, and remote program responses are relayed to your screen. Basic Telnet supports very little in the way of encryption or other complications to this simple model. This simplicity is Telnet’s major flaw; without encryption, data passed over a Telnet session can easily be sniffed by computer miscreants on your network or on intervening networks if the client and server aren’t on a single network.

The Telnet clients and servers that ship with Kerberos implementations support data encryption, although the encryption features aren’t always implemented automatically. If your network already uses Kerberos, switching to Kerberized Telnet makes sense and can provide much-needed encryption to these sessions. Chapter 9 covers Kerberos and its version of Telnet.

The rlogin protocol, named after its client command, is an extremely simple remote access tool. It provides no-password access from an account on one system to a like-named account on another system. This security model is, by modern standards, appallingly lax, so rlogin is almost never used today. (A Kerberized variant is much better in this respect, though.)

A variant of rlogin, this command enables you to run a single program from a remote computer on your local computer. Like rlogin, its security is poor, so it should almost never be used.

SSH may be the most popular remote text-mode access tool in use, having displaced Telnet as the tool of choice. SSH’s most important advantage over Telnet is that it supports encryption, making the protocol a much safer choice than Telnet. SSH also supports tunneling non-SSH protocols (including X sessions), file copying (via the scp command), and the ability to replace rsh’s functionality.

This tool isn’t a network protocol; instead, it’s a method of physically connecting two computers. In days of old, mainframe computers served a collection of potentially dozens of dumb terminals, which were connected to the mainframe via RS-232 serial connections, or something similar. Linux can work in the same way, which can give two users access to one computer if you’ve got an old dumb terminal or if you run a terminal emulator on another computer (even an extremely old one). RS-232 connections are usually fairly secure because they’re direct physical connections without intervening networks. They’re inflexible, though; you can’t easily use them to connect to a server from other arbitrary systems.