Many people are unaware of the open source resources that are available for the commercial UNIX® platform. As a matter of fact, a large percentage of the free software available in the Linux® space today actually has a much longer history within the UNIX operating system environment. It is important to understand, both for system administrators and end users, the purposes and functionality of these free resources compared to the vendor supplied tools and applications that come with commercial UNIX. You can use the information in this article as a starting point to take advantage of the free software that is available to you as a commercial UNIX administrator or user, thus making you even more productive.
Before exploring the differences between free verses vendor-supplied software for commercial UNIX too deeply, it would be wise to understand the history and philosophy of the GNU project (see Resources).
The GNU project, led by Richard Stallman, commenced in 1984 in the hopes of producing a free UNIX-like operating system. It was very unusual to have the source code for any of the UNIX utilities, since the copyrights for the various UNIX operating systems were tightly held at the time. Stallman left his job at MIT and began writing software.
Stallman intended for all of his code to be free -- free as in freedom as opposed to free as in beer (cost). Even in the beginning the distribution of his code cost money (just as many Linux distributions today), but once you had the code, you were free to use it, change it, and redistribute it. This is the basis of the GNU GPL (General Public License).
Hopefully, most people are aware of the difference between simply free software and open source software. Even the term "free software" can be misunderstood, depending on whether it is referring to cost or freedom. This article does not make a distinction. Most open source software is released under the GNU GPL or compatible licenses. If you are not planning on re-releasing any changes to your code, you should not need to worry about which license is used.
You can find a range of different free software licenses available that support a wide range of Free and Open Source Software (FOSS) -- from GNU supported projects like GCC (GNU gcc and gcc-c++ compilers) and Emacs to non-GNU projects like MySQL, Mozilla, Apache, and larger applications and environments like Gnome, KDE, and OpenOffice.
With a few exceptions, all free software is compatible with commercial UNIX variants. You can use this free software either to augment or replace functionality and tools within your commercial UNIX environment. How you install, use, and operate these free software tools is entirely up to you.
This section compares the differences between the tools and utilities distributed with commercial versions of UNIX and their free software counterparts.
Because of the open nature of the FOSS tools, they have tended to develop faster and with more features than the proprietary versions. When the GNU project first started out, their goal was to emulate UNIX and provide a compatible system. Over time, their tools have surpassed the commercial UNIX systems in functionality. It is already the case, and will probably become more prevalent, that UNIX vendors include a certain number of FOSS tools with their commercial UNIX operating systems.
Let's look at two examples: tar and find. The general commands are the same. Both the commercial version and the GNU version of tar combine files into a single archive file. Both versions of the find command search directories looking for files with certain characteristics. The GNU versions of both commands, however, have far more options.
For instance, GNU tar can automatically compress the output file with various compression algorithms using an option on the command line rather than requiring a separate post compression step. This is accomplished with the -z, -Z, -j, or even the very flexible -use-compress-program options. Another defining feature of the GNU version of tar is that it can deal with large filenames that most commercial versions of tar are unable to deal with, even though most commercial UNIX environments have incorporated the ability to support long filenames within the file systems for some time.
If you look at the GNU version of find, it has additional options to restrict the depth of parsing using the -maxdepth option. This option is useful if you only want to parse one or two directories rather than the entire subtree. The GNU version of find also has a -regex option. This option allows for full regular expressions to be used in matching filenames rather than the simple wildcard matching found in commercial find commands.
There are a few instances where the commercial version of a tool might actually have additional options that the GNU version does not support. There are various reasons for this. There might be a platform-specific option, or it might be an option that is not documented that internal operating system scripts might utilize. Because of these discrepancies, it is unwise to completely replace the existing UNIX tools with GNU versions. However, the use of a standardized suite of FOSS tools across a range of UNIX machines, particularly within a heterogeneous environment, can make system administration significantly easier.
A major benefit of installing GNU tools is platform independence. This allows you to standardize tar files using the GNU format and GNU options among different UNIX versions.
As mentioned, it's not a good idea to install GNU versions of tools over top of commercial tools. Where you choose to install them depends on multiple factors, including the standard for your distribution and your personal preferences. It is important to understand the implications of installing applications in a UNIX environment. This section discusses:
- Directory structures created and used in installation
- Conventions for upgrading applications
- Implications on the
PATHvariable - Choosing preferences between standard tools and GNU versions
Let's take a look at two options for installing duplicate tools.
Most applications assume there will be a certain directory structure where supporting files will go. For instance, Emacs might be installed in the /usr/local/bin directory, but its supporting files and templates would be in the /usr/local/share directory. Other applications require the sbin, var, and lib directories. No matter what base path the application is installed in, it creates and uses the other directories. As mentioned earlier, picking / or /usr as the prefix would be unwise due to the possibility of overwriting system files.
Some tools allow you to have a prefix on the name of the application to distinguish them from the commercial tool. A common example is tar. You can install the GNU version of tar with the command name gtar. This installs the tool in a standard location without overwriting system-critical tools, but still allows you to use either version if needed.
Installing in separate directories and renaming the tool are two options for installing duplicate tools without overwriting important system utilities. Both methods have advantages. These options could even be combined to gain the manageability of a separate location with easy access of different program names. If you install the tools in a standard location, you will not need to modify any PATH variables. The downside of installing tools using a different name is the slight learning curve encountered as people learn different command names.
If you decide to install tools in a separate directory, you can still decide whether this directory structure will be shared among many applications (such as /usr/local or /usr/contrib), or whether there will be a separate directory structure for each application (such as /opt/perl and /opt/find.) In many instances, it is even advisable to use a different directory for different versions of the same application. Keeping the applications in separate directories can make upgrades and long-term maintenance easier, since all the files for a specific tool are in one location.
Providing links to extra directories
You could add all of these extra directories to the PATH variable, or use a standard location and provide links to the extra directories. This way the end user won't see any difference. Managing the package is also easier. For example, you could install Samba in /opt/samba-3.0.21a and then create a symlink from /opt/samba to /opt/samba-3.0.21a. Then in /usr/local/bin and /usr/local/sbin, you could create links to /opt/samba/bin/smbclient, /opt/samba/sbin/smbd, and so forth, as shown in Listing 1 below).
Listing 1. Directory listings showing possible symlinks for applications
#ls -l /opt lrwxrwxrwx 1 root root 5 Jan 19 14:34 samba -> samba-3.0.21a drwxr-xr-x 9 root root 216 Aug 17 16:12 samba-3.0.14a drwxr-xr-x 9 root root 216 Jan 19 14:30 samba-3.0.21a lrwxrwxrwx 1 root root 7 Aug 23 2004 mozilla -> mozilla-1.7.2 drwxr-xr-x 10 root root 1696 Feb 11 2004 mozilla-1.4 drwxr-xr-x 11 root root 1352 Aug 23 2004 mozilla-1.7.2 #ls -l /usr/local/bin/smb* lrwxrwxrwx 1 root root 24 Aug 16 16:02 smbclient -> /opt/samba/bin/smbclient lrwxrwxrwx 1 root root 24 Aug 16 16:03 smbpasswd -> /opt/samba/bin/smbpasswd lrwxrwxrwx 1 root root 21 Aug 16 16:02 smbtar -> /opt/samba/bin/smbtar |
This might seem somewhat clunky at first with so many layers of indirection, but the link creation process can be scripted -- it doesn't change very often. The benefit of this method is that when an application needs to be upgraded, say for instance you needed to install a new version of Samba, you would install it to a new directory, such as /opt/samba-3.0.22. Then all you would need to do is change a single link so /opt/samba points to this new directory. This also allows you to keep old versions around in case you run into an intractable bug and need to downgrade. Downgrading is nearly impossible with a shared destination directory.
If you download a binary distribution of an application, you need to be careful because they sometimes have hard-coded paths built in. Hopefully they follow the standard for your UNIX variant. If they do not and you find this causes you concern, a few cleverly crafted symlinks might provide you with the standardization you crave.
Finally, some users who want to integrate FOSS tools into their environment might not be administrators. Many times they don't know how to proceed, because the installation wants to install the program to a system-wide location. The solution is identical to the procedure listed above, except you must use a directory structure within your home directory that you can modify. You can create a folder with a new /lib /bin /sbin directory structure and install the applications within these. If you add these directories to your $PATH variable, it will be no different than if the system administrator had installed them in a standard location.
Most of the free software available for UNIX is available as source code. That does not necessarily mean that compiling the code yourself is the only or best method for installing a package. Many applications are distributed in binary format for the major commercial UNIX versions.
Compiling applications yourself gives you many advantages. You can specify all of the compile-time options that might be more optimized than a binary distribution, or it might provide features that the binary version does not include. You can also specify the exact path to install the tool. If you do compile, it is wise to keep a record of the exact compile-time options. This allows you to keep all of the same features and optimizations during an upgrade.
You can simplify the installation and deployment of FOSS software tools by using one of the many pre-packaged binary distributions. Different versions of the FOSS software tools are either supplied as a simple archive or, more often, they are supplied using a standard package format used to manage native software packages within the operating system.
Using these packaged binary distributions means that you can continue to use the package management tools you are familiar with. Because you do not have to worry about compiling the software, you often don't need to worry about any additional packages that are required to build the application.
Removal and monitoring of the installed software is easier. In addition, upgrading a binary package from one release to the next is also simpler than removing self-compiled versions and then recompiling and installing the new distribution using the same compilation, build, and deployment options.
Unless you have unique requirements, a binary distribution is probably the best idea.
This article examined how to integrate some of the FOSS tools into a commercial UNIX variant. Installing FOSS software into your commercial UNIX environment has many advantages. Not only does it give you the flexibility to install and maintain it the way you want, but you also have the freedom to modify the product to best fit your needs. UNIX could not possibly have grown to the stable and pervasive computing environment it is today without the support and use of so many free tools.
Learn
-
Learn more about the GNU project and the Free Software Foundation.
-
For an article that defines what free software is, see The Free Software Definition.
-
For an article that explains the difference between free software and open source software, see:
Why "Free Software" is better than "Open Source".
-
The intersection of ethics, law, business and computer software is the subject of these groundbreaking essays and speeches included in Free Software, Free Society: Selected Essays of Richard M. Stallman.
-
Visit OpenSource.org, the center of activity for much of the open source revolution.
-
For some history of open source software, see the developerWorks article "The hard roots of open source software" (developerWorks, May 2000).
-
Get free applications for:
-
Read Eric Raymond's brilliant open source manifesto The Cathedral and the Bazaar.
- Want more? The developerWorks eServer zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on the eServer brand.
- The IBM developerWorks team hosts hundreds of technical briefings around the world which you can attend at no charge.
Discuss
- Participate in the eServer™ forums.
-
developerWorks blogs: Get involved in
the developerWorks community.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
