Using PCs As Terminals

Everybody has a definition of what old is concerning computer hardware. And then there’s the question of usability with old hardware.

I’ve got a superb example of how old can still be useful. And I guarantee this will impress you. Below is a video of a 1984 Digital VT-240 terminal. Yes, a terminal, not a PC. And yes it’s 25 years old.

At the 3:13 mark in the video, the person who has this terminal was able to connect it to a network server, browse the web with it, and later shows that it can actually act as an access point for music playback to a central media server.

Watch the video below and be amazed:

The above proves a few things:

1. With Linux or UNIX, you truly can use even the oldest of computer hardware.
2. As long as the computer box has some way of connecting to a Linux or UNIX server, it can still serve a useful purpose.
3. It is not required to have a GUI operate a computer or terminal as long as you know how to navigate using text-only means.

The example you see above is done via a very old-school client/server setup. Everything that is loaded on the terminal side is fed through the network and loaded directly from the server. In the above instance, the network server is Linux-based using the NFS protocol.

Could you do something like this?

Yes – however it’s most likely true you’re not going to drag out an old 25-year-old terminal to do it with (nor would I recommend it). But you probably do have some old PCs lying around. If you do you’re in luck because it’s really easy to set them up to be terminals.

Things to know before you start

The best and easiest way to get a client/server setup is to do it wired-only. And what I mean by that is not to use wireless networking. This is not to say you couldn’t use it, but it makes initial setup a bit of a problem.

Older PCs don’t handle wireless networking very well. The wireless signal reception will be weak on the client side, software and driver support can prove to be a problem, and remote connectivity sessions aren’t exactly great at handling abrupt sessions disconnects/drops. When that occurs (and it will with wireless), the session can sometimes get locked whereas you have to reboot the server and the client just to get things running again.

You will encounter none of these problems with a wired network.

Again I will say that this doesn’t mean you cannot use wireless. If you have to, go ahead. Just be aware of the potential issues with session control.

The server

Operating System

The computer you choose to use as the server must be loaded with an operating system that can handle long file names properly. This means you can use any NT-based Windows (Windows NT, 2000, XP and up). On the Linux side you can use any distribution you want as all of them handle long file names easily.

Apps

You also must make sure the server can run the apps you need to get what you want done.

For file serving, you don’t have to worry about any particular app.

For media serving however, you do.

On the Windows side you’ve got plenty of choices such as Windows Media Player, WinAMP, iTunes (yes it does run under Windows), VLC and plenty of others.

On the Linux side there are so many choices it’s ridiculous. You can play direct from the command line or use a GUI-based way of doing it. The best place to start is to load up your preferred Linux distro of choice and use the provided player. If it’s not to your liking, examine the repository to see what else is available. In Ubuntu for example, you can simply go to Add/Remove and see what’s there.

App resolution

Another important thing to take into consideration is the resolution of an app. The best kind take up the least amount of screen area. Ideally, you want a program that does not require anything over 1024×768 to display it fully. This will allow a program to load faster over the network and put only minimal graphic requirements on the client side.

Serving sessions

You have a few choices here and it depends what OS the server uses.

If using a Windows server, you could simply use RDP (Remote Desktop Protocol). This is built-in to 2000 and XP.

However it’s better overall if you use a method of serving sessions that will work on both Linux or Windows clients. The easiest of the lot is VNC.

VNC comes with almost all distributions of Linux. For the Windows side, you can use TightVNC. This is a nice small server program that simply sits and waits for requests to serve sessions. In addition, you can use the TightVNC client for Windows-based clients. (Look to the download page and pick the "viewer executable" – it’s nothing but a single executable you can use on Windows clients and works wonderfully).

Setting up a Linux server to accept VNC connections is relatively painless. General documentation on how to do this is here – BUT (and this is a big but) – it is better if you read the documentation for your specific Linux distribution on how to do it. If you were using Ubuntu for example, you’re much better off searching for VNC related documentation in the Ubuntu wiki or Ubuntu forums.

Bear in mind setting up VNC on Linux is a very common thing. It will not take you hours upon hours to figure it out. At worst, it will probably take 30 minutes of your time to set it up if you’ve never done it before. Maybe less. The documentation that’s out there on how to do it is very extensive and well-written.

The client

The system requirements for a client PC are next to nothing.

If using Linux:

You don’t even need a hard drive on the client. All you need is a computer box that has VGA resolution and you can boot off a "live" CD, such as Ubuntu. If the box has wired network connectivity, it’s more or less guaranteed that the card will be detected on boot, an IP address will be acquired and you can establish a VNC connection to the server or just launch a terminal prompt and connect that way.

If using Windows:

Windows requires to be installed on a hard drive in order to use, so it has to be there.

It is also required to have at least a 1024×768 resolution to get anything done on it.

Everything else is optional – even the sound card. All the stuff you need to do will be on the server, so the only requirement is the application needed to establish a remote session.

The advantages of a client/server setup

That old computer box may be barely able to do anything on its own, but when acting as a terminal connecting to a server, you’re using the power of the server to do things rather than on a local level.

For example, we’ll go super old-school an say you’re connecting a Windows 98 PC to a server running Windows XP. Windows 98 cannot run IE 8, but Windows XP can. You’re completely bypassing the limitations of the client computer to take advantage of what the server is capable of – and it works great.

Client PCs can be run "dangerous" because they do not connect to the internet directly. The server is the one that is in the "danger" territory, so that has to be updated. But as far as the client is concerned it doesn’t have to be due to the fact it always connects via a remote session to said server. For example, if the client PC is Windows XP with Internet Explorer 6, you can leave the browser at 6 because you’re never going to use it. You’ll be using IE 8 via the remote session so you’re covered.

It’s also a distinct advantage keeping all the stuff you do on a single computer box, that being the server. You won’t have to keep jumping from PC to PC just to track down files you’ve saved.

If you’ve got some old PCs lying around, consider the client/server setup. Whether you do it the Linux way or Windows way, it’s convenient, it’s easy and the only cash you’ll have to spend is probably for network cable and nothing else!

Got a question or two?

I do understand that some of what’s described above may seem a bit on the vague side – but that’s only because there are several different ways you can go about setting up a client/server environment.

If you have questions, feel free to ask and I’ll do my best to answer.