Linux as a Work Environment Desktop

Tips and suggestions for using Linux on the desktop in a non-Linux workplace.

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.

Design Tools

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.

Development Tools

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)

This results in the correct makefile definitions being
automatically loaded by make at runtime.

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.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.