When introduced to Linux and the option of compiling a favorite software package from source, most Windows administrators wonder why they'd ever want to do that. This tip explains why there are some compelling reasons to roll your own binary.
First, let's look at the back story. Traditionally, Windows has practiced a method of package distribution that provides good ease-of-use and reliability through its use of precompiled binaries. As a best-effort attempt to reach a wide variety of software configurations and hardware implementations, precompiled binary packages represent a consistent and efficient model for delivering software packages, updates, service packs and so forth.
Even Linux offers its own forms of precompiled distribution -- typically handled by some native package manager such as RPM or YuM -- to meets average users' needs. This practice aligns perfectly with the Windows model, but depends on the distribution provider or some interested third-party to precompile and distribute Linux-compatible software goods.
Another difference between the way Linux handles third-party packages and additions versus Windows is in package management utilities, such as YuM and YuMEX for Fedora Core, apt-get for Debian, etc. Linux provides users with a single general-purpose utility to help them acquire and install software applications from any third-party vendor. Best of all, such applications are compiled specifically for whatever platform and revision a given package manager recognizes or supports.
Such Linux utilities do a phenomenal job of resolving platform-dependent issues transparently on behalf of their users, and can save considerable time and effort spent (or wasted, if the desired end-result is not attained) that might otherwise go to identifying and resolving installation issues by hand.
Now, we're back to where we're started, when the Windows admin is introduced to the option in Linux of compiling a favorite software package from source. Any sane admin, at this point, would wonder why anyone would do that task.
In most cases, there are only a few, if any, truly compelling reasons for compiling packages from source. It is time consuming and requires meticulous attention to detail for large code-bases. It also assumes an intimate knowledge of Linux compiler tools, not a fair or safe assumption to make of every user.
As we said before, however, there are also some equally compelling reasons to roll-your-own binary from raw source code, particularly when building custom-tailored server installs. Let's look at two very good reasons:
- Not every precompiled package is complete.
Perhaps your version of LAME (a popular MP3 encoder) lacks support for a certain necessary audio format, as is the case for many pre-packaged distributions. The only way to get it is by compiling from source, and the same thing is true for many other applications and services as well.
- You've got a situation in which the same software runs slower on machine X versus machine Y
Again, precompiled binaries are often built upon whatever is parameters are considered bare-minimum at compile-time. If a development lab specifies a 500MHz processor with 128MB of memory as bare-minimum, a software package will be tailored to meet those specifications. The only surefire way to get the absolute best performance out of a Linux application is to compile it on the target machine where it will run.
For admins news to Linux or end-users of Linux-based solutions, precompiled packaging has the same appeal as to the Windows segment. For Linux professionals and expert developers, build-your-own is part of the basic equation.
Only in those cases where a binary maps to a true one-size-fits-all situation does it make sense to implement a generic code library compiled against generic standards, as is often the case when coding or deploying network process images in your environment.
It's a key test of a Linux professional's discrimination to know when to use precompiled binary, which is usually when basic building blocks are involved, and when to compile, which is most of the time.
About the authors: Ed Tittel is a full-time freelance writer and trainer based in Austin, TX, who specializes in markup languages, information security, and IT certifications. Justin Korelc is a long-time Linux hacker who works with Ed, and concentrates on hardware and software security topics. Together, both contributed to a recent book on Home Theater PCs; right now, both are busy at work on a book about Linux-based MythTV environment.