Section 11.1. What Can GUI Logins Do?

11.1. What Can GUI Logins Do?

GUI logins can be used for the same broad classes of purposes as text-mode logins, as described in Chapter 10to run user programs remotely or to administer the computer. Because GUI logins are, well, GUI, you can run a wider range of programs using them than you can with a text-mode program. This includes GUI word processors, graphics editors, web browsers, and more. Programs that work best when they can display arbitrary fonts and graphics will work best with (or even require) GUI login tools. Because Windows programs are more likely to require GUI access than are Linux programs, GUI login tools are particularly important if you want to run Windows remotely.

GUI login tools' advantages come at a price, though: increased network bandwidth consumption, which translates into lower speed. You can use a text-mode login tool quite comfortably over a dialup link or an overloaded local network, but a GUI tool used in the same environment might be painfully slow. Details do differ, though, depending on the tool and the programs you use.

Several GUI access protocols are available today. In the Linux world, X and the Remote Frame Buffer protocol (most commonly implemented by VNC) are the most popular remote-access tools, and these are the two tools that are described in this chapter. An interesting variant is the NoMachine (http://www.nomachine.com) NX Server and NX Client. The NX Server is built around X, while the NX client can connect to other systems using the NX, X, or RFB protocols, as well as protocols that are more common in the Windows world.

Remote X access involves a lot of back-and-forth transfers, but X delivers some types of data using few bytes. VNC, by contrast, requires more bandwidth but fewer transactions. Thus, X is likely to perform best on low-latency connections, whereas VNC performs best on high-bandwidth connections. Tunneling, encryption, compression, and other options can influence both protocols' performance, though. If speed is a problem, you may need to experiment with both protocols.

Both X and VNC are a bit odd as network protocols go, but in different ways. X reverses the usual client/server relationship, as described in the next section. VNC is frequently run as a user process rather than as a conventional all-users server, as described in Section 11.4.2. Both oddities have implications for how you use the protocols. At their simplest, they require users to log in using a text-mode protocol before a direct GUI connection can be made. Ways to eliminate this requirement exist for both protocols, but these require extra configuration, which can be intimidating to those unfamiliar with the tasks at hand.

Unfortunately, neither X nor VNC encrypts data by default, so both protocols, by themselves, are risky ways to access a computer. (VNC does encrypt initial password exchanges, though.) One common solution to this problem is to use the SSH protocol to tunnel the GUI protocolthat is, to use an SSH connection as a carrier for the GUI connection, thus encrypting the GUI traffic. Alternatively, you can use a full-fledged virtual private network (VPN) to encrypt traffic. Precisely how to handle such encryption schemes is different for X and VNC, though.