(IDG) -- Over the last two years (a long time by Internet standards), the status of Unix freeware has changed significantly. In June, 1996, Max Airborne and Erin O'Neill covered a different era of Solaris "shareware," as they called it, in SunWorld Online. Back then, shareware, aka public domain software, seemed skimpy compared to the options available for Windows.

Today, however, most programmers are aware that high-quality open source software can be downloaded for a wide variety of common applications such as compilers, word processors, network monitors, fonts, interpreters, database management systems, games, and e-mail agents. In fact, free software dominates several market niches, among them Web service, scripting languages, e-mail, and others.

Despite its wide use and distribution, myths about the quality and reliability of freeware have seen free software banned in some workplaces. In these cases, legitimate concerns about training, support arrangements, and disaster recovery have mushroomed into the mistaken prohibition of free software. The reality, says independent industry expert Eric Raymond is that open source software (roughly, programs for which anyone can examine the source code) is actually safer than most commercial applications.

In short, the quality of free software is likely at least as good as its commercial counterpart. (For some background on this, see the SunWorld article on Eric Raymond). This said, your time will be better spent working productively, rather than fighting to restrict yourself to commercial software.

MORE COMPUTING INTELLIGENCE

IDG.net home page

SunWorld home page

Reviews & in-depth info at IDG.net

IDG.net's server hardware page
IDG.net's workstation page

IDG.net's personal news page

Subscribe to IDG.net's free daily newsletter for sys admins

Questions about computers? Let IDG.net's editors help you

Search IDG.net in 12 languages

News Radio

Fusion audio primers

Computerworld Minute audio news for managers

Where and how

So how do you find useful free software? Mostly the same way you find any other useful software: talk to co-workers, ask experts, read magazines, look in catalogs (several CD-ROM publishers specialize in packaging free software), search FAQs and Usenet, and attend conferences. To make things even easier, several Web sites have organized collections of free software of potential interest. The "Solaris Freeware Project," run by Steve Christensen (see IDG related links, below) is one such site which is mirrored on several hosts around the world.

This is an ideal resource for users who already know what they're after. Suppose you need a copy of the GNU compiler, gcc, installable under Solaris 2.6 for SPARCs. It'll take just a few clicks to find the last three versions already generated and ready for download. If you don't find what you're looking for, let Christensen know. Our experience is that he and his team of volunteers often update offerings within 24 hours.

Newcomers to freeware, however, will want a trustworthy guide like Celeste Stokeley's Shareware & Public Domain Software for Unix. Stokeley, like Christensen an experienced independent consultant, reviews both individual packages and whole sites. You'll quickly find most of what you need within a couple links of these entries from the related links below.

Once you've found your application, you still face an important question: Source or binary?

Which will it be?

Downloading binary images, by far the most seductive, will provide the user with an executable that can be used right away. Source code, however, is slightly more difficult to handle and has to be compiled first. Still, the choice is not always clear, and source offers a certain flexibility that can make it the better option.

The case for source

Perhaps the best argument for retrieving source and generating the applications yourself is the fact that this is how most freeware is designed. Developers package it to be downloaded, unpacked, generated, and installed directly on your machine. When you download a binary executable, you rely on someone else to do those two middle steps for you, on a different host. It's a lucky coincidence if the runtime environment on your machine and hers are similar enough that what she made on her machine works on yours.

Christensen, an expert in binary generations (his site downloads millions of carefully-prepared Solaris executables daily), cautions against downloading binaries. "I do all of the work myself since I want to be able to stand behind what I present on my pages," he said. "It is always better to do the compiles yourself since you then can be sure the options you want are included and your machine's properties are taken into account," he said.

Consider, for example, lsof, an indispensable application that reports hidden information in files and network connections, which is available as a binary download for nearly eighteen different varieties of Unix on one FTP site alone.

Vic Abell, associate director of the Purdue University Computing Center and maintainer of the lsof FTP site, provides cryptographic authentication of downloads, is precise about version compatibility, and knowledgeable about subtle differences between Unix flavors, and still does not recommend downloading precompiled lsof binaries!

Why? Abell gives three reasons which illustrate nicely the general problems associated with all binary downloads.

Full use of the software: A binary executable generated on a machine with only a single processor, or a default file system, might not properly take advantage of the multiprocessors or advanced filesystem on your machine. The result will not be optimized for your system.
Compatibility: When lsof is compiled on the system where it is to be used, it has the best chance of being enabled to support that system and to have access to the same header files that the kernel uses. Some Sun kernel patches introduce changes in kernel structures, reflected in the header files of that system, which are only available to lsof if it is compiled there.
Security: As is usual with security issues, full explanation of all the implications is a large task, one that takes more space than this article can afford. Easiest to grasp is the possibility of sabotage of the binary image. Working from source that you can review yourself slashes this risk.

Beyond the compatibility and security issues mentioned above, there are other reasons to prefer source. First, a few of the legacy hosts with which we work are still on the far side of a 1200 baud bottleneck. It can be quicker to download source (which is generally smaller than executables) and generate it than to download the binaries directly.

A more common problem than connection speeds, however, is so-called shared-object turmoil. Windows installations are notorious for DLL complications, where different applications insist on installing DLL files in conflicting locations. Unix suffers from a mild form of the same malady, whose most frequent symptom is an executable that only complains about missing shared-object libraries when launched.

The full story behind the disease is a long one. The most frequent cause, though, is a package generated to be installed in a particular directory, say, /usr/local, while local policy requires you to install it elsewhere, perhaps in /var/contributed or $HOME/package. This means that when the application goes to look for the file, it wont find it. Convenience, the whole point of downloading a binary, is lost when you have to start locating the missing files by tracking down missing .s? archives.

Surprisingly, the package mechanisms most vendors provide -- Sun's pkgadd, Red Hat's RPMs, Hewlett-Packard's depots, etc. -- address essentially none of these problems. It's disappointing that vendors have chosen not to address security issues or arbitrate shared-object conflicts in these applications. As Jeffrey Hobbs, software engineer for Siemens, remarked on the deficiencies of these managers: "It's a botch."

So why does anybody download binaries at all?

The case for binaries

Despite all this binary bashing, there are still a few cases in which binaries are the better, and sometimes the only, choice. The following are two compelling reasons to use binary.

Missing compilers: This can make using source simply impossible.
Convenience: While most modern freeware generates very reliably, swiftly, and quietly, saving even 10 minutes of compilation time can be important when a client has a short attention span.

Some users might like to add a third reason: they don't like to do their own generations because they're not programmers, and they fear the debugging they'll have to do in case a generation fails. But in our experience, generations rarely fail. In fact, generations are usually so trouble-free that working with binaries is the alternative that takes more programming expertise.

This is because installations of binary downloads frequently fail from shared-object confusions. Although we've worked through these problems ourselves often enough that they don't slow us down much now, we usually advise others who run into them simply to abandon the binary and start over with a fresh generation. If you can avoid learning how to trace LD_LIBRARY_PATH to disentangle muddled shared-object libraries, so much the better.

Incompatibilities are rare when working from a high-quality archive, such as Christensen's. But when we do run into problems, we don't hesitate to generate the software from source.

The correct answer to the question "Binaries or source?", as is so often the case in computing, is: both, and each in its place.

Off-Net downloading

A number of times already we've abbreviated one step as "download." This generally requires no more comment, as most readers have more-or-less direct connections to the Internet at large, where all the sites we discuss can be found. If you're like us, though, you'll occasionally work with isolated machines, ones that are "off-Net." Sometimes those are the machines most in need of software. Many of these machines have some provision for e-mail, which can be used to accept smaller data packages which can be later assembled into an application. As a last resort, our favorite "sneakernet" is by way of floppy diskettes. If you use either of these, chances are you'll run into limits on the size of individual files.

A particularly robust way to cut up big files so they'll fit through a narrow pipe (as with floppies or e-mail applications) is to make them seven-bit clean and split them as follows:


        uuencode $PACKAGE $PACKAGE | split -20000

        # transfer xa? by hand through e-mail or floppies.

        cat xa? | uudecode

Splits at 20000-line boundaries ensure that the split results don't exceed 1,240,000 bytes, which fits comfortably on a single floppy.

Problems

The freeware installations we see work remarkably well. You'll probably find and start using your first freeware in less time than it takes to read this article. To help troubleshoot, Christensen told us of the few difficulties in binary downloads that recur most often in the correspondence he receives, and his solutions.

Problem: When I download, the file isn't in gzip format.

Solution: This is usually because the browser has already gunzipped the file and you don't realize it.

Problem: When I gunzip the file, it is not in tar format.

Solution: You have not read the instructions and don't realize you have a package that needs to be unpacked first.

Problem: I have downloaded and unpackaged the files -- now how do I compile the software?

Solution: The programs are already compiled.

Problem: I try to run a program and it says it cannot find some file or library.

Solution: Many of the programs, like gcc, require that users have installed the developers packages that come on the Solaris CD. This is fixed by installing the packages.

Christensen concludes that "the only [insurmountable] problems people have are that they have to be root to install [several] packages and they can't get the root user on their machine to do that." He emphasized, though, that the answers to 9 out of 10 questions could be found in the standard READMEs or FAQs.

Where to begin

What freeware will you first retrieve for yourself? To outfit a Solaris (or any Unix) host for productive work, you'll likely want the following: gzip, unzip, and UUDeview, to restore the most popular formats of compressed and encoded files top, which monitors in real time the processes keeping your machine busiest gcc and gnumake, if you work with freeware source lsof, mentioned above, for tracking input/output resources lynx, for swift, stable Web browsing MSWordView, which lets you read the latest Microsoft Word documents from your Unix workstation

In addition, there are several applications that improve the utilities Sun and other vendors supply with their base operating systems. The sendmail and bind versions Unix vendors nominally support, for example, are several generations of security fixes behind current releases. XFmail or Postilion are handy mailing agents that end-users generally prefer to mailtool.

Finally, gamers tell us that netrek and Maelstrom are compelling reasons to keep workstations powered up after work hours.

Conclusion

It's easy to find free software that performs useful and even indispensable operations for your Solaris or other workstation. Bearing in mind your system specifications and the nature of the freeware you want to install, as per our discussion above, freeware can provide a highly economic and highly functional alternative to commercial software. The careful organization and preparation volunteers like Christensen and Stokeley have done make it likely that you'll find the freeware you want, and install it successfully with just a few minutes of your own concentration.

Cameron Laird and Kathryn Soraiz manage their own software consultancy, Network Engineered Solutions, from just outside Houston, TX. Reach Cameron at cameron.laird@sunworld.com. Reach Kathryn at kathryn.soraiz@sunworld.com.