Which of the following systems cannot run Linux:
- IBM mainframe
- Mac G4
- Nokia 770 Internet Tablet
- Sharp Zaurus PDA
- Linksys WRT54G router
If you said none of them, you were right. Beyond that, the last four do run Linux as they come from the factory. And this is just a small sample. My point is that while Linux isn't everywhere it is in places you may not expect and, well, it could be everywhere.
Now, TUX focuses on Linux on the desktop. For the TUX reader, each month we show you how to use more applications programs on desktop systems and how to better utilize the KDE desktop. In other words, to do more things with your desktop computer where we just happen to promote Linux rather than other operating systems.
I want to talk about other potential Linux desktop users that, well, don't need to read TUX. That is, all they need is a reliable desktop system that runs a very limited number of applications. A typical office user.
I went to a bank two days ago to open an account. I sat down and watched as the employee brought up the right screen in her web-based application to create a new account. She filled in a few forms--that is, web pages--made some photocopies of paperwork, printed out some pages for me to sign and I had an account.
While this system wasn't a Linux system, I could see no reason why it couldn't be. It is likely that she would sometimes run a word processor or possibly a spreadsheet on the system and she might have email. But, that is pretty much it. This, to me, is the perfect place where a more secure and lower cost Linux based solution would not require any user training.
Looking forward a bit, if the web can become the user interface of the future, the number of cases where a Linux desktop cannot just be a direct replacement for other systems decreases. Yes, I need to explain this a bit.
Traditionally, well-designed applications programs minimize the number of actions the user needs to take to get the job done, quickly checks for errors and, in general, makes the user's job easier. Web-based solutions have not been able to compete because you almost always need some mouse-based actions as well as keyboard-based actions and you need to send one web page to get the next one. All that just slows down the process.
Let me offer a simple example. You have a form where you enter an address. With a typical application it would be desirable for the system to accept a postal code and automatically fill in the city and state information. Until recently, this would have been impossible to do unless either a complete look-up table was sent to your browser--something that would take considerable time--or you sent the page with the postal code and had the server return a new page with the city and state filled in.
Not so with AJAX. As soon as you entered the postal code, an action could automatically be initiated to fetch the city and state information and put it into the form currently being displayed. The A in AJAX stands for asynchronous. This means that you can continue filling in fields and the information, as soon as it was available, would be displayed.
Today, new applications are being designed to take advantage of this capability. For a developer, this means less work because there is no need to program new user interfaces--the web browser becomes that interface. If the application complies with web standards, any system with a compliant browser--FireFox or Opera being the best and most portable choices--it makes no difference what operating system is running on the client system.
If you are writing applications software, using a web-based interface you will both save yourself development time and produce a portable application. You also reduce support and maintenance costs because everyone uses the same version of your software. If you are just on the user end of the software you also win because you can pick the best platform to use in your office without concern about the availability of a version of the application for that platform.