As we've seen over the last 18 months or so, Linux has stormed up the league tables in terms of server-side operating systems. Many people, in fact, are now beginning to see that there are options beyond a small number of large companies that traditionally held sway over the high-end operating system market.

The next logical step in this evolution of Linux is the migration from the back-end services, where it has proved itself admirably, to the desktop. This switch is more difficult to accomplish, as Linux was traditionally developed with server-side processing in mind. Until recently, there had been no concerted effort to develop applications for the end user that could compete against the dominant players.

While many argue that Linux is still not ready to act as a desktop OS, there isn't too far to go before this scenario becomes feasible. In this article, I aim to give you a feel for some of the challenges that Linux enthusiasts may meet when setting out to make this an environment more appealing to their sensibilities, as well as some tips on resolving them.

I work as a developer in a small office environment. The project that I'm working on at the moment has put me in an ideal situation to experiment with Linux as a serious desktop environment. I admit that this scenario may not be appropriate for everyone, but I attempt to deal with handling some of the more common tasks under Linux.

The project concerns Java development, with the main development platform being Solaris. The tasks that I've had to perform include designing the project, developing and testing code, tracking project defects, and general day-to-day administration, such as mail, research, and document reading and writing.

Most of the design work that takes part in the office involves the use of UML as the modeling language. In UML there are a number of conventions for representing different aspects of object-oriented program design. While there are a plethora of diagramming tools available for the Windows environment, tools for the Linux environment are generally lesser known, harder to come by, and maybe not as polished as their counterparts in the Microsoft world. Because the development environment that I work in is predominately Java, I had the advantage of not having to base my search wholly in the Linux application area; a good tool that is written in Java is cross platform by nature. While searching for suitable tools, I came across two likely candidates.

One of these tools is called ArgoUML. The web site for the tool, listed in Resources, describes ArgoUML as a cognitive design tool. It attempts to examine your design and provide suggestions on what may be lacking, or point out discrepancies in your design. The version of ArgoUML that was available from the web site was only a development version. They seem to have moved recently to a new site and revamped their development efforts.

On Windows, the Rational Rose UML tool has a pretty powerful presence in the object-oriented design world. Being able to read and write project files that are compatible with Rose is a great advantage. MagicDrawUML is a commercial UML design tool. Written in Java, it is completely cross-platform, and by exporting your projects in Rational Rose format, you can also share your work with others. As a side note, many people claim that Java can be quite slow, so what the developers did with this tool is pretty impressive. The user interface is as responsive as any you might use in a Windows or Linux environment. The downside of this product is that it doesn't come free. However, the license fees are a fraction of Rational Rose, and in a commercial development environment, it may be a worthwhile investment.

In this section, I try to give you some idea of the tools that are available for Linux that can be used to develop and build a Java project.

The build environment we use has been set up with Make. This tool is pretty standard on Linux installations. Make is available on a wide variety of platforms, so it is a good choice for cross-platform projects. The bulk of platform independent macros and targets can be defined in standard Makefiles. By using the following strategy, you can minimize the fuss that is involved in building over multiple platforms.

First, define an environment variable ARCH, which is set to whatever the uname command returns. This can be done at login time by adding the following command to your .bash_profile (for bash users):

export ARCH=<\#145>uname'

Then, move all your platform specific Make routines and definitions to a makefile with a name such as Makefile.$ARCH, where $ARCH is what is returned by uname on the particular platform. Finally, in your main makefile, add the following line to include the platform specific definitions in your make commands:

include Makefile.$(ARCH)

The next stage in your build environment is finding a Java compiler that has been ported to Linux. At the moment, there are a number of Java compiler and interpreter projects in the pipeline. But so far, for production work, the options are the Java development kit that has been ported by the Blackdown team, or the JDK that is available from IBM. Depending on your situation, there may be preferences towards either JDK. Both these JDKs support the latest specifications from Sun.

Another advantage of using Java is the cross-platform nature of the byte code that your source code is compiled into. This means that if you need to use extra class libraries or jar files, there is no need to go hunting for platform specific implementations. However, many Java applications do in fact include native libraries, and this limits execution of these applications to the platforms that they have been ported to. Depending on how much you need to run these applications, this may not be a problem. For example, the project that I'm working on makes use of the Java Messaging Specification (JMS), defined by Sun. The Java Message Queue (JMQ) is a product released by Sun that implements JMS. JMQ hasn't been ported to Linux as of yet, and as a result, I am unable to test my code against it in Linux. I do need to compile my code against it, and because the libraries are mostly in jar format, I can copy the jar libraries onto my local machine and still successfully build my application against it.

Applications to help you develop code are two a penny. Each editor or IDE has their evangelists, so making a recommendation in this area is always a touchy subject, but I will mention my favorite editor. Due to job requirements, I was forced to learn vi a few years ago. Since then, I have moved onto vim and gvim and never looked back. I've tried other IDEs now and again, such as JBuilder and even Microsoft's Developer Studio, but until they implement the vi keymaps, those IDEs will only ever get a look from me. Where these IDEs do have advantages over vi is in the debugging aspect, but sometimes a well-placed println() method will do just as good a job.

Vim and gvim have color syntax highlighting, auto-indentation and other features that are too numerous to list. These editors can even handle write-build-debug, if set up correctly. An extremely powerful and easy-to-use function of vi clones is macros. A little thought about repetitive tasks in an editor can result in a simple but powerful macro to help you do what might have taken a lot longer in a less powerful editor.

What we're left with, then, are two of the more project-management type features that are usually left until last in any self-respecting project: source code management and bug/defect tracking. The most widespread source code management packages are SCCS, RCS and CVS. SCCS isn't available as an open-source application, which leaves CVS and RCS. RCS is suitable for smaller projects. I recently had the opportunity to work with CVS. While, for the most part, it uses the same format history files as RCS, the user interface to CVS is much more elegant. Added to that, you have multiple-developer support and remote-client support. That last feature comes in quite handy in my setup. Our CVS repository is stored on a Solaris machine. In my aim to use all things Linux and to prove that it can actually be done, I installed a CVS client on my Linux machine (this would probably come standard on some installations). By setting the CVSROOT environment variable to access the CVS repository on the Solaris machine remotely, I can manage my source code locally. CVS uses rlogin to execute the CVS commands remotely, so make sure that you have set up the proper access on the remote machine. The CVSROOT environment variable needs to follow the following format in order to have it access a remote repository:

export CVSROOT=:ext:hostname:CVSRepository

Good open-source bug/defect tracking software is hard to come by. I could only find two that looked at all stable. One of these was dropped because it didn't fully meet our requirements. The only real possibility available to us was the bug-tracking application used by the Mozilla team. This application has a decent web-based user interface, with a MySQL database back-end. It is highly configurable, and once we got over a few quirks, it was up and running reasonably quickly.

Some of the typical Linux utilities come in very handy when developing a project. Not just for the work involved in coding and testing, but also the utilities that simply make life a bit easier. For example, the commands find, cat, awk and egrep tend to be used quite a lot for general system administration, finding your way around your source files, and writing small scripts that make a job easier. Without installing something like Cygwin for Windows, you would be hard-pressed to find similar “life-improving” utilities on Microsoft platforms.

A particular class of utility that is more directly related to code development would be a “pretty printer”, or utilities that can tidy your code for you so that they conform to a particular standard, such as the Sun Microsystems Java coding standard, or your own company's coding standard. The indent utility is available on most Linux systems, and by specifying a range of options, you can control how the final output is formatted. At the moment, our project conforms to the Sun Microsystems coding standard. When I first went looking for the options for indent that would format Java code to the correct standard, I came across the Jindent utility. This is an indenter written in Java, so again, it is completely cross-platform. By default, it formats to the Sun standard, and when creating your own configuration file, you can modify its output.

For backup purposes, we keep most of our development work on UNIX servers. The majority of our client machines are Windows NT. The UNIX machines we work with are equipped with NFS and SAMBA. By sharing out these drives, we can access those resources locally without having to log into the remote machine. A Linux machine can mount both NFS and SAMBA drives that have been shared out. By keeping the same directory structure as that on the remote machine, you reduce the need to produce machine specific makefiles. For example, if a required jar library is located under /opt/FSUNjmq/lib/jms.jar on the remote machine, the makefiles that you developed can run on both the remote UNIX machine and your local Linux machine without any modification, by mapping /opt/FSUNjmq to /opt/FSUNjmq on your local machine. Commands for sharing out remote drives are similar to the following. For NFS:

share /opt/FSUNjmq

For SAMBA, edit the /etc/smb.conf file, copying one of the example shares, modify it to point to the correct directory, and make sure to give your user name access permission. It is not always possible to work solely off your local machine; there will be times when you will need to log in to the remote machine to run various processes, such as when there isn't a port available for the application you wish to test against, or when you need to copy, move or access large amounts of data. In addition, logging into the remote machine will give you better network performance. The rlogin command gives you easier access to remote machines than telnet. With rlogin, you can set up access permissions so that you are not required to enter a user name and password every time on login. By creating a .rhosts file in your remote home directory, and by adding your local machine name, you will be able to drop into the remote machine easily. Just make sure that your .rhosts is set to read/write permission for the owner only, and that there is no group or global access allowed. Otherwise, your automatic authentication will not work.

One of the annoying things I found about logging into remote machines is that you have to set up all your shell preferences a second time. This can be overcome by configuring a common profile file and making this available to both your local machine and your remote machines. Create a .commonProfile file on your remote home directory, and mount your remote home directory locally. So, in addition to your /home/username directory, you also have a /remote/username directory. In your local and remote profiles, you can then source your .commonProfile. Any changes you need to make can now be made only once, and they will be reflected in both environments.

One important point about remote access to your UNIX servers is that when setting up a user account for yourself on your local machine, you should set the same username, uid and gid that you have been assigned on the remote machine. This makes life much easier in terms of write, mount and login permissions. Some of the more experienced users may be familiar with NIS; this is a method for keeping a central repository of users and passwords across a number of UNIX machines. With a bit of research, and a suitable network configuration, it may be possible to set up your Linux machine to use NIS to allow other users to access your machine. This avoids the need to duplicate each user id and group id when you add a new user to your machine.

An extremely useful ability is being able to run X Window clients from the remote machine on your local machine. This gives you access to the remote machine in a graphical environment. However, even though you can run remote applications in a window on your local X Window display, in some cases there are incompatibilities between what the remote application is expecting from a UNIX X Window system and what your local X Window server provides. A classic case would be if your X Window server is running in 16-bit color, but the remote application can only run in 8-bit color. Rather than having to shutdown your X Window session and restart in 8-bit color, you can either start up a second X Window session with 8-bit color locally, or you can run the remote window manager so that it displays on your local machine. The command for this is:

X :1 -query remotehost

The “:1” means that you want X to run as your second display. This requires you to set the display variable on the remote machine to your second display:

export DISPLAY=yourhost:1

In the way of general advice on how to handle day-to-day tasks that would normally be done in Windows, I offer the following:

Probably the most generic function in any office these days is reading and writing Microsoft documents, whether Word, Excel or Powerpoint. StarOffice provides an entire suite of applications that are capable of reading and writing Microsoft format documents. With their latest version, they have provided even more support for Microsoft integration.

For e-mail, there are loads of mail clients to choose from. However, this can be restricted depending on the type of mail server you use. You should have no problem finding mail clients for POP and IMAP mail. Since I've already mentioned StarOffice, I'd like to point out that it comes with a built-in mail client for POP and IMAP mail. Netscape also includes POP and IMAP support. Difficulties can occur if your company has selected to use Microsoft Exchange as its e-mail server and hasn't opened up IMAP or POP access to it. At the moment, there are no IMAP compatible clients available for Linux. As far as I know, your options here are limited to e-mail clients that will only run in Windows (if anyone knows any differently, give me a holler!). See below for more information on how to combat this.

Unfortunately, Linux doesn't supply all the capabilities that are necessary in today's office. We are more often than not resigned to having to share our machine with Microsoft products. WINE provides the ability to run Microsoft products natively in Linux; however, it leaves a lot to be desired. For these cases, VMWare is a clever application that allows you to run an instance of another operating system within your Linux operating system. Check it out if you haven't come across it. For me, VMWare provides the ability to run Microsoft Outlook reading e-mail from our Exchange server. It seems a bit of an overkill to have another operating system running in order to just read mail, but we don't always get what we want.

Printing is an area that can cause a number of headaches when setting up a Linux operating system; however, printer setup tools and driver support is improving rapidly. Setting up a network printer under Linux can be pretty straightforward if you follow the rules. One thing to watch out for is when you have a printer that doesn't seem to have its own driver. There are plenty of resources on the Web detailing how to set up a specific printer even if it doesn't seem to be supported. For example, we have a Gestetner PCL printer in the office, but by using the HP LaserJet III printer driver I now have access to this printer.

In summary, there are many areas that must be dealt with when trying to successfully run a Linux operating system in an environment that doesn't necessarily support it. I've tried to give you some idea of how I got around the problems I've encountered. In the Resources section, I've listed some of the web sites that have come to my aid in researching how to do something in Linux that is normally done in Windows. But remember, not everything can be done through Linux, and sometimes you will have to fall back to non-Linux applications.

Resources